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Preface 


I  began  my  search  for  a  thesis  topic  with  the  intention 
of  identifying  and  solving  an  engineering  problem  of  inter¬ 
national  scope.  Fortunately,  those  more  learned  and  exper¬ 
ienced  in  the  solution  of  engineering  problems  directed  me 
toward  a  more  realistic  goal.  The  desire  to  address  a 
substantive  problem  was  encouraged  and  remained. 

The  need  to  develop  a  completely  integrated  set  of  VLSI 
CAD  tools  became  clear  to  me  in  the  wee  hours  of  a  Spring 
morning  as  I  struggled  to  complete  a  VLSI  design  project 
using  two  incompatible  CAD  tools. 

Perhaps  this  work  is  not  as  revolutionary  as  I  had 
envisioned  but  I  believe  it  provides  a  solid  basis  for  the 
development  of  the  elusive  integrated  toolkit  of  VLSI  CAD 
tools.  I  have  learned  much  and  have  developed  a  high  regard 
for  those  who  have  made  VLSI  technology  available  to  all  of 
us . 

Many  of  the  ideas  developed  during  the  characterization 
of  the  CAD  toolkit  were  developed  during  a  review  of  Paul 
Losleben's  excellent  and  comprehensive  paper  on  VLSI  [17], 

I  am  indebted  to  Hal  Carter,  my  thesis  advisor,  for 
permitting  this  project  and  for  his  enthusiastic  approach  to 
my  work,  his  concise  suggestions,  and  tactful  criticisms.  I 
offer  a  special  thanks  to  Bill  Sutton  for  his  prompt  and 
careful  reviews  of  the  segmented  drafts  that  preceded  this 
final  product. 


Tom  Vermillion 
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Abstract 

The  literature  indicates  that  the  success  of  future 
VLSI  design  efforts  is  contingent  upon  the  evolution  of  a 
new  design  philosophy  and  upon  the  production  of  a  special 

v  I 

kind  of  engineer,  a  VLSI  design  engineer.  ^The  lack  of  an 
integrated,  compatible  set  of  VLSI  CAD  tools  has  been  sug¬ 
gested  as  a  serious  problem  which  prohibits  the  optimization 
of  the  academic  curricula  necessary  to  produce  the  required 
VLSI  design  engineers. 

This  thesis  proposes  that  the  CAD  tool  problem  may  be 
solved  through  the  development  of  a  VLSI  CAD  -'"toolkit"."  The 
characteristics  of  an  integrated,  technically  complete, 
academically-oriented  VLSI  CAD  toolkit  have  been  presented.. 
A  systematic  method  to  integrate  CAD  tools  was  developed  and 
supported  through  the  design  of  a  set  of  CAD  tool  evaluation 
metrics..  Finally,  a  prototype  VLSI  CAD  toolkit  and  its 
custodian  were  designed,  implemented,  and  evaluated. 

The  characterization  of  the  integrated  toolkit,  though 
not  complete,  appears  to  constitute  a  solid  basis  for  future 
work.  The  evaluation  metrics  and  methodology  were  simple  to 
implement  and  provided  absolute  and  relative  measurements  of 
the  “"level  of  presence"  of  desired  characteristics  in  tool¬ 
kit  components.  .  The  evaluation  metrics  show  promise  but 

further  application  of  the  metrics  to  collections  of  CAD 

\ 

tools  will  be  required  if  a  high  level  of  confidence  is  to 
be  assured.  ■- H / 
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THE  SYSTEMATIC  INTEGRATION  OF  VERY  LARGE  SCALE 


INTEGRATED  CIRCUIT  COMPUTER-AIDED  DESIGN  TOOLS 
INTO  A  TOOLKIT  OPTIMIZED  FOR  ACADEMIC  APPLICATIONS 


I.  Introduction 


Background 

The  successful  defense  of  the  United  States  is  predi¬ 
cated  upon  a  deterence  of  conflict  through  possession  of 
military  systems  that  are  more  capable  and  survivable  than 
those  possessed  by  potential  opponents.  Today,  the  enhance¬ 
ment  of  military  systems  primarily  requires  the  reduction  of 
their  cost,  size,  weight,  and  power  requirements  while  si¬ 
multaneously  increasing  their  speed,  intelligence,  reliabil¬ 
ity,  and  survivability.  The  enhancements  are  being  imple¬ 
mented  chiefly  through  the  replacement  of  manual  and  semi¬ 
automatic  electro-mechanical  sub-systems  with  intelligent, 
fully  automatic,  electronic  modules. 

Current  technology  provides  the  capability  to  construct 
electronic  modules  composed  of  many  active  and  passive  elec¬ 
tronic  devices  arranged  on  a  very  small  piece  or  chip  of 
silicon.  The  silicon  electronic  modules  require  very  little 
power  and  are  housed  in  extremely  small  packages.  These 
microelectronic  modules,  implemented  through  the  integration 
of  many  electronic  devices,  are  known  as  integrated  circuits 
(ICs).  Integrated  circuits  are  classified  according  to  the 


density  of  individual  devices  integrated  on  a  single  silicon 
chip.  The  generally  agreed  upon  classifications  of  IC  inte¬ 
gration  are: 


Small  Scale  Integration  (SSI)  :  1  -  10  dev. 

Medium  Scale  Integration  (MSI)  :  10  -  100  dev. 

Large  Scale  Integration  (LSI)  :  100  -  100,000  dev. 

Very  Large  Scale  Integration  (VLSI) :  100,000+  dev. 

One  author  proposes  an  expansion  of  the  IC  classifica¬ 
tion  system  to  accommodate  a  new  classification.  Ultra  Large 
Scale  Integration  (ULSI)  [27].  The  expanded  classif ication 
system  defines  VLSI  as  200,000+  devices  and  ULSI  as 
10,000,000+  devices. 

The  development  and  integration  of  VLSI  circuits  into 
military  systems  are  essential  elements  of  the  successful 
defense  of  the  United  States.  The  U.S.  Department  of 
Defense  (DOD)  has  underscored  this  assertion  through  its 
$400  million  program  for  the  research  and  development  of 
Very  High-Speed  Integrated  Circuits  (VHSIC).  The  VHSIC 
program  has  been  called  the  most  ambitious  and  important 
Federal  program  since  the  United  States  began  the  explora¬ 
tion  of  space  [33].  The  VHSIC  program's  goal  is  the  devel¬ 
opment  of  high-speed,  reliable,  silicon  chips  that  will 
ensure  continued  U.S.  superiority  in  defense  electronics 
[33]  . 

The  implementation  of  VLSI-based  defense  systems  will 
necessitate  many  changes  within  the  DOD  and  within  the 
organizations  and  companies  that  provide  support  to  the  DOD. 
Perhaps  the  most  important  changes  will  be  required  in 
academic  institutions  where  curricula  must  be  revised  to 
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produce  a  new  type  of  engineer,  the  VLSI  design  engineer 
[6]  . 


Paul  Drongowski,  in  a  paper  describing  the  VLSI  curric¬ 
ulum  at  Case  Western  Reserve  University,  suggests  that  VLSI 
design  engineers  fall  into  two  categories:  1)  "tall-thin" 
engineers  capable  of  spanning  VLSI  design  from  architecture 
to  circuit  analysis,  and  2)  "short-fat"  engineers  who  are 
particularly  adept  at  some  specific  design  task  [9],  The  j 

successful  design  of  future  VLSI  circuitry  requires  the 
education  and  hiring  of  a  new  class  of  engineers,  "tall- 
thin”  VLSI  engineers,  with  broad  backgrounds  in  electronics, 
system  architecture,  software,  and  computers. 

The  early  development  of  integrated  circuitry  was  ac¬ 
complished  by  people  primarily  skilled  in  the  physics  and 
materials  of  solid  state  devices.  The  initial  growth  of  IC 
density  (hence  functional  complexity)  was  much  slower  than 
that  being  experienced  today.  Historically,  the  design  of 
ICs  and  the  translation  of  IC  designs  into  actual  hardware 
has  been  done  by  teams  of  "short-fat"  engineers  using  manual 
techniques.  The  teaching  and  use  of  manual  design  and 
implementation  techniques  has  been  a  satisfactory,  although 
laborious,  method  of  creating  SSI,  MSI,  and  LSI  integrated 
circuits.  Unfortunately,  previous  IC  design  methods  and 
implementation  techniques  are  less  effective  with  VLSI  de¬ 
signs  . 

The  increased  functional  complexity  and  device  density 
(with  its  attendant  reduction  in  geometrical  tolerances) 
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associated  with  VLSI  circuitry  have  necessitated  a  reevalua¬ 
tion  of  the  current  approaches  to  IC  design  and  production. 
It  is  generally  recognized  that  computer-aided  design  (CAD) 
equipment  and  programs  are  critically  important  elements  of 
future  VLSI  design  methodologies  [4,17,19,28,34,40].  Educa¬ 
tional  institutions  are  presently  faced  with  rapidly  imple¬ 
menting  new  curricula  to  address  these  design  issues  at  a 
time  when  the  industrial  community  is  attracting  the  most 
qualified  teachers  [33].  The  U.S.  Air  Force,  and  its  engi¬ 
neering  school,  the  Air  Force  Institute  of  Technology 
(AFIT) ,  have  not  escaped  the  need  for  curricula  changes  nor 
the  loss  of  qualified  instructors. 

AFIT  has  expanded  its  graduate-level  electrical-engi¬ 
neering  curriculum  to  include  courses  and  individual  re¬ 
search  efforts  designed  to  produce  engineers  and  managers 
qualified  in  the  design  and  evaluation  of  VLSI  circuits  and 
systems.  The  importance  of  automated  design  and  evaluation 
philosophies  and  their  associated  techniques  are  fundamental 
themes  of  each  VLSI  course,  laboratory,  and  research  pro¬ 
ject.  The  success  of  the  AFIT  VLSI  curriculum  rests  in  the 
ability  to  expose  engineers  and  managers  to  the  methodolo¬ 
gies  and  processes  associated  with  VLSI  design  in  a  very 
short  period  of  time  (typically  3  courses).  The  availabili¬ 
ty  of  high  quality  VLSI  CAD  programs  is  essential  if  AFIT 
students  are  to  rapidly  and  effectively  acquire  a  useful 
background  in  VLSI  design. 

The  current  generation  of  CAD  programs,  often  referred 
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to  as  "tools",  evolved  during  independent  academic,  commer¬ 
cial,  and  DOD  projects.  Those  concerned  with  VLSI  circuitry 
developed  and  implemented  the  CAD  tools  necessary  to  achieve 
their  specific  goals.  This  independent  growth  of  CAD  tools 
has  led  to  the  establishment  of  generally  disjoint  sets  of 
application-specific  tools  with  various  levels  of  compati¬ 
bility.  The  willingness  of  several  universities  to  share 
their  locally  developed  tool  collections  with  AFIT  has 
substantially  decreased  the  time  needed  to  develop  a  VLSI 
curriculum  at  AFIT.  Although  the  use  of  these  tools  has 
been  very  beneficial  over  the  past  years?  a  problem  has  been 
observed  which  must  be  corrected  if  the  AFIT  VLSI  curriculum 
is  to  fully  achieve  its  goals. 

Problem 

The  problem  is  twofold.  First,  the  tools,  which  are 
widely  varied  in  form, function,  and  complexity,  require  too 
much  time  to  learn  their  effective  use.  Second,  design 
projects,  the  most  highly  productive  and  instructive  compo¬ 
nents  of  the  VLSI  curriculum,  are  limited  to  a  low  level  of 
complexity.  The  projects  are  limited  because  the  systematic 
access  to  the  broad  spectrum  of  CAD  tools,  essential  for 
realistic,  complex  VLSI  design  efforts,  is  not  possible  with 
the  the  current  arrangement  of  AFIT  CAD  tools.  Although 
there  is  a  wide  range  of  powerful  CAD  tools  available  to 
AFIT  students,  the  tools  reside  in  different,  and  frequently 
incompatible,  tool  collections.  The  time  required  to  com- 


pensate  for  tool  incompatibilities  inhibits  student  use  of 
many  tools. 

The  basis  of  the  problem  is  the  lack  of  an  integrated, 
compatible  set  of  VLSI  CAD  tools,  which  may  be  easily 
learned,  and  utilized.  This  serious  problem  prohibits  the 
optimal  use  of  the  time  available  to  produce  the  high  quali¬ 
ty  VLSI  engineers  and  managers  necessary  to  meet  the  chal¬ 
lenges  facing  the  DOD  in  the  next  few  years. 

The  solution  to  the  problem  is  the  integration  of 
available  VLSI  CAD  tools  into  a  technically  complete  "tool¬ 
kit"  which  is  easy  to  learn,  to  use,  to  update,  and  to 
manage . 

This  thesis  will  describe  the  characteristics  and  com¬ 
ponents  of  an  integrated,  technically  complete, 
academically-oriented  VLSI  CAD  toolkit.  The  attributes  of 
an  academically  sound  VLSI  CAD  toolkit  and  its  components 
will  be  identified.  A  set  of  evaluation  metrics  (mathemati¬ 
cal  relationships  to  measure  and  weight  the  desirable  attri¬ 
butes)  will  be  developed.  Furthermore,  a  systematic  method, 
based  upon  the  attributes  and  metrics  described  above,  will 
be  proposed  to  enable  selection  of  the  most  suitable  tool¬ 
kit  components  from  a  generally  disjoint  VLSI  CAD  tool 
inventory. 


Assumptions 

Several  assumptions  have  been  made  to  reduce  the  scope 
of  this  thesis  to  a  level  manageable  in  the  few  months 
available.  It  is  assumed  that: 
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1.  That  the  reader  has  an  understanding  of  the  fabri¬ 
cation  processes  used  to  create  the  fundamental  components 


of  silicon-based  integrated  circuits. 

2;  That  the  reader  has  a  good  background  in  semicon¬ 
ductor  devices  and  technologies. 

3.  That  the  reader  has  a  good  background  and  working 
skills  in  at  least  one  high-level  computer  language  that 
permits  the  use  of  structured  programming  techniques. 

4.  A  subjectively  developed  set  of  CAD  tool  attributes 
and  evaluation  metrics  will  be  acceptable  to  the  reader  as 
rigorous  and  comprehensive  enough  to  demonstrate  that  the 
toolkit  component  selection  methodology  is  sound. 

5.  Tailoring  the  tool  evaluation  metrics  to  suit  the 
needs  of  academic  institutions  does  not  nullify  their  value 
when  using  them  to  evaluate  commercially-developed  CAD 
too 1 s . 

6.  The  characteristics  of  a  VLSI  CAD  tool  can  be  ade¬ 
quately  observed  by  using  a  simple  test  input  and  sequen¬ 
tially  exercising  all  of  the  tool  options  on  that  input. 

7.  Discrepancies  and  deficiencies  noted  in  an  eval¬ 
uated  tool  are  caused  by  the  tool  structure  as  advertised 
and  documented  and  not  by  improper  installation  of  the  tool 
or  undetected  local  modification  of  the  tool. 

Summary  of  Current  Knowledge 

The  critical  importance  of  CAD  .tools  to  the  successful 
design  of  VLSI  circuitry  is  well  documented.  CAD  software 


has  been  referred  to  as  the  "backbone"  of  modern  VLSI  design 
[28].  One  theme  present  in  much  of  the  literature  reviewed 
is  that  continued  CAD  tool  improvements  are  absolutely  es¬ 
sential  to  make  VLSI  design  available  to  people  not  neces¬ 
sarily  skilled  in  semiconductor  technologies.  Access  to 
VLSI  design  by  the  disciplines  that  support  or  use  VLSI 
circuitry  is  required  if  the  major  problems  impeding  VLSI 
evolution  are  to  be  resolved.  [13,20,31]. 

Much  work  has  been  reported  concerning  the  development 
and  improvement  of  specific  CAD  tools.  Several  discussions 
of  the  future  of  VLSI  design  address  the  need  to  develop  a 
connectivity  between  the  various  design  levels  (usually  in 
the  form  of  a  centralized  database). 

The  proceedings  of  recent  design  automation  (DA)  con¬ 
ferences  indicate  there  are  three  major  areas  where  work  is 
being  concentrated:  1)  identification  and  refinement  of 
technologies  that  permit  an  increase  in  IC  component  densi¬ 
ty,  2)  development  of  specific  CAD  tools  to  cope  with  in¬ 
creased  design  complexities  and  3)  identification  of  IC 
design  methodologies  which  will  increase  the  productivity  of 
IC  designers. 

Many  efforts  to  establish  metrics  for  software  evalua¬ 
tion  have  been  reported.  Most  of  the  metrics  observed  were 
based  upon  the  detailed  constructs  inherent  in  a  particular 
language  or  class  of  languages.  One  particularly  valuable 
source  of  metric  development  information  was  found  in  a 
report  prepared  by  Dean  and  McCune  concerning  the  evaluation 


of  advanced  tools  for  software  maintenance  [8]. 


Few  efforts  were  found  that  addressed  the  specific, 
central  issue  of  this  thesis,  a  methodology  for  VLSI  CAD 
tool  integration.  One  effort  to  integrate  engineering  de¬ 
sign  tools,  a  project  to  create  a  Designer's  Workbench  by 
Bell  Laboratories,  was  reviewed.  Several  useful  ideas  have 
been  found  in  a  report  on  the  delivery  of  CAD  tools  for  the 
Designer's  Workbench  113].  If  a  single  philosophy  or  view¬ 
point  seems  to  prevail  throughout  this  thesis,  it  has  emerg¬ 
ed  from  a  review  of  the  excellent,  comprehensive  discussion 
of  VLSI  CAD  tools  prepared  by  Paul  Losleben  [17]. 

Approach 

This  thesis  approaches  the  IC  CAD  tool  integration  from 
an  academic  viewpoint.  The  methods  developed  are  intended 
for  application  in  the  academic  arena.  However,  some  may  be 
useful  to  the  industrial  community. 

First,  past  and  current  discussions  concerning  VLSI 
design  methods  will  be  reviewed.  Next,  a  review  of  publish¬ 
ed  literature  and  documentation  pertinent  to  the  use  and 
evolution  of  VLSI-oriented  CAD  tools  will  be  performed.  The 
information  obtained  from  the  reviews  will  provide  the  basis 
for  the  development  and  presentation  of:  1)  Support  for  a 
VLSI  design  philosophy  which  incorporate  an  integrated  CAD 
toolkit,  2)  the  metrics  necessary  to  evaluate  a  VLSI  CAD 
toolkit  and  its  component  tools,  and  3)  a  methodology  to  use 
the  metrics  developed  to  construct  an  integrated,  VLSI  CAD 


toolkit  which  will  adequately  support  aggressive  VLSI  cur¬ 
ricula. 

The  metrics  and  methodology  developed  will  be  evaluated 
through  a  partial  application  of  them  to  the  VLSI  CAD  tools 
currently  available  at  AFIT.  A  prototype  toolkit  will  be 
suggested  to  support  the  soundness  of  the  methodology.  Mis¬ 
sing  tools  will  be  identified  and  the  high  level  design  of 
the  program  necessary  to  control  the  toolkit  will  be  com¬ 
pleted. 

Finally,  recommendations  will  be  made  for  future  work 
concerning  the  integration  of  VLSI  CAD  tools. 


Sequence  of  Presentation 

Chapter  II  opens  with  a  brief  chronology  of  the  evolu¬ 
tion  of  VLSI  circuits  and  a  review  of  IC  design  methodolo¬ 
gies.  The  prevailing  IC  design  philosophy  and  its  applica¬ 
bility  to  VLSI  requirements  is  discussed.  The  essential 
characteristics  of  a  viable  VLSI  design  methodology  are 
summarized.  Finally,  the  critical  VLSI  design  role  of  inte¬ 
grated  IC  CAD  tools  is  established. 

Chapter  III  establishes  the  general  structure  of  an 
ideal  kit  of  VLSI  CAD  tools  and  illustrates  the  use  of  the 
toolkit  by  outlining  a  "typical"  design  session. 

Chapter  IV  completes  the  characterization  of  a  useful, 
complete,  maintainable,  integrated  VLSI  CAD  toolkit  by  pre¬ 
senting  a  detailed  description  of  the  ideal  toolkit  struc¬ 
ture  . 


Chapter  V  details  the  development  of  the  metrics  that 


will  be  used  for  toolkit  and  tool  evaluation.  The  mechanics 
of  CAD  tool  integration  are  also  presented. 

Chapter  VI  provides  a  discussion  of  the  work  done  to 
create  the  examples  provided  in  the  appendices  and  should 
serve  as  a  first-level  evaluation  of  the  validity  of  the 
integration  method  presented  herein. 

Chapter  VII  Provides  summary  of  this  author's  work  and 
recommendations  for  future  work  concerning  the  integration 
of  IC  CAD  tools. 
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I I .  VLSI  Design  Methods 

Chronology  of  VLSI  Development 

The  evolution  of  the  integrated  circuit,  and  certainly 
the  VLSI  circuit,  was  not  a  miraculous  occurrence  but  was  a 
rather  difficult  effort  marked  by  many  engineering  and 
scientific  milestones. 

Several  significant  milestones  in  the  evolution  of  VLSI 
circuits  are  summarized  below  [35]. 


1947  (Dec) :  Bell  Laboratory  physicists  Walter  H. 
Brattain  and  John  Bardeen,  following  suggestions 
made  by  physicist  William  Shockley,  demonstrated 
electrical  amplification  by  using  the  properties 
of  electric  fields  near  the  surface  of  a 
germanium-based  "point-contact"  device.  John  R. 
Pierce  calls  the  device  a  "transistor". 

1947:  Immediately  following  the  demonstration  of 
the  "point-contact"  transistor,  Shockley  suggests 
the  possibility  of  transistor  action  in  a  struc¬ 
ture  that  sandwiched  an  n-type  semi-conductor 
between  two  p-type  semiconductors.  Shockley  calls 
the  structure  a  "junction  transistor".  Shockley 
could  not  prove  his  theory  because  there  was  no 
way  to  construct  the  "junction  transistor"  at  that 
time. 

1948  (June) :  The  military  decides  there  is  no 
need  to  classify  the  transistor  and  Bell 
Laboratory  holds  first  public  demonstration  of  the 
transistor.  Public  response  is  somewhat  indiffer¬ 
ent. 

1953  (June) :  Through  the  leadership  of  the  Army 
Signal  Corps,  standards  for  transistor  operating 
characteristics  were  proposed. 

1954:  Texas  Instruments  Inc.  (TI)  announces  the 
first  transistor  made  of  silicon. 

1956:  Shockley,  Brattain,  and  Bardeen  are  awarded 
the  Nobel  Prize  in  physics  for  research  in  semi¬ 
conductors  and  for  the  invention  of  the  transis¬ 
tor  . 
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1957:  John  T.  Wallmark,  working  at  Radio  Corpora¬ 
tion  of  America  (RCA)  laboratories,  is  awarded  a 
patent  for  the  field-effect  transistor  (FET) . 

1958:  Fairchild  Camera  and  Instrument  Corporation 
produces  the  first  device  built  by  diffusion,  the 
diffused-base,  mesa  transistor.  The  device  was 
called  a  mesa  transistor  because  of  the  "stacked" 
construction  of  the  transistor's  base,  emitter, 
and  collector  regions. 

1958:  Jean  Hoerni,  a  physicist  with  Fairchild, 
invents  the  planar  process  for  transistor  con¬ 
struction  and  suggests  a  metal  deposition  tech¬ 
nique  for  component  inter-connections. 

1958:  Jack  Kilby,  an  engineer  working  for  TI, 
assembles  the  first  "integrated  circuit"  ( IC ) - 
The  all  silicon  circuit  was  a  phase-shift  oscilla¬ 
tor  constructed  with  mesa  transistors. 

1959  (January) :  Robert  Noyce  of  Fairchild  Semi¬ 
conductor  Inc.  enters  in  his  notes  a  description 
of  an  "integrated  circuit"  which  would  incorporate 
diffused  resistors  and  evaporated  metallic  inter¬ 
connections.  Noyce  and  Kilby  are  considered  inde¬ 
pendent  inventors  of  the  IC. 

1959  (March) :  Kilby  designs  and  builds  a  flip- 
flop  using  monolithic  germanium.  The  "solid  cir¬ 
cuit"  was  unveiled  at  the  Institute  of  Radio  Engi¬ 
neers  show. 

1961:  The  first  commercially  available  monolithic 
integrated  circuit  is  marketed  by  Fairchild.  The 
IC  was  a  flip-flop  built  using  resistor-transistor 
logic  (RTL)  and  contained  four  bipolar  transistors 
and  two  resistors. 

1962:  Steven  Hof stein  and  Frederic  P.  Heiman, 
young  engineers  working  for  RCA,  produced  the 
first  metal  oxide  semi-conductor  FET  (MOSFET) . 
They  demonstrate  the  usefulness  of  the  MOSFET  by 
building  a  MOSFET-based,  multi-purpose  logic 
block.  The  logic  block  contained  16  MOSFETs  on  a 
2,500-square-mil-chip  of  silicon. 

1965  (August) :  Fairchild  announces  the  dual  in¬ 
line  (DIP)  IC  package. 

1965:  Robert  Widlar,  a  designer  with  Fairchild, 
develops  the  first  practical  integrated  circuit 
operational  amplifier  (opamp) ,  the  uA709.  Widlar 
also  designed  the  UA702,  uA710,  and  the  uA741 


opamps . 


1966:  Autonetics  delivers  the  first  silicon-on- 
sapphire  (SOS)  chip  to  the  Massachusetts  Institute 
of  Technology.  The  chip  was  a  matrix  of  6,144 
diodes  for  a  character  generator  in  a  display. 

1967:  Fairchild  announces  the  first  read-only 
memory  (ROM)  chip.  The  ROM  was  a  64  bit  MOS 
memory . 

1971:  Intel  Corporation  unveils  the  first  micro¬ 
processor  (uP)  ,  the  4  bit  4004.  The  chip  was  a 
silicon-based,  p-channel  MOS  design  and  measured 
110  by  150  mils. 

1971:  Intel  Corporation  announces  the  first  8-bit 
microprocessor,  the  8008.  The  chip  used  MOSFET 
circuitry  and  contained  approximately  2,900  de¬ 
vices  . 

1979:  IBM  announces  the  first  64-K  (65,536  bits) 
dynamic  random-access  memory.  This  chip  has  been 
called  the  first  VLSI  circuit. 


Approaches  to  the  Design  of  Integrated  Circuitry 

The  evolution  of  integrated  circuitry  has  been  accompa¬ 
nied  by  a  non-linear  increase  in  chip  complexity.  In  1964, 
Gordon  E.  Moore,  then  director  of  research  at  Fairchild 
Semiconductor  Inc.,  was  the  first  to  predict  the  growth  of 
IC  complexity  when  he  suggested  that  the  complexity  would 
double  every  year  [26].  No  significant  departure  from  that 
prediction  has  been  observed,  in  fact,  Moore's  prediction 
is  often  referred  to  as  "Moore's  Law"  [17,26],  Demands  upon 
the  resources  required  to  accomplish  an  IC  design  have 
increased  in  a  non-linear  manner  proportional  to  the  in¬ 
crease  in  IC  complexity.  The  design  philosophies  and  ap¬ 
proaches  used  to  manage  and  develop  IC  design  resources  have 
not  matured  sufficiently  to  meet  VLSI  requirements.  The 


remainder  of  this  chapter  focuses  on  the  current  approaches 
to  IC  design  and  what  must  be  done  to  extend  these  approach¬ 
es  to  encompass  VLSI  design  requirements. 

The  Early  Design  Approaches.  The  approach  taken  to 
design  the  first  IC  in  1958  prevailed  through  the  mid  1970s. 
The  experience  necessary  to  accomplish  electronic  design 
resided  primarily  in  those  scientists  and  engineers  familiar 
with  solid-state  physics  [20].  Electronic  design  was  an  art 
applied  to  the  sciences  that  provided  the  basis  for  elec¬ 
tronics  [18].  The  early  IC  chips  were  designed  by  one  or 
two  people  who  had  few  constraints  placed  on  their  designs 
or  their  design  methodology  [17].  Communications  between  IC 
designers  and  the  designers  of  systems  employing  ICs  were 
very  poor  consequently/  both  groups  established  essentially 
independent  goals.  Most  major  IC  design  efforts  were  pro¬ 
jects  to  assemble  a  family  of  chips  that  encompassed  all  the 
basic  functions  of  boolean  logic.  Few  chips  contained  com¬ 
plex  functions  and  system  designers  were  faced  with  the  task 
of  integrating  large  numbers  of  the  SSI  ICs  to  perform  a 
complex  task.  The  IC  development  process  from  conception  to 
production  was  a  manual  one. 

The  design  process  is  simply  summarized.  A  chip's 
architecture  was  dictated  by  the  desired  logic  function. 
Once  a  function  had  been  selected,  the  function  variables 
were  manually  minimized  and  translated  into  logical  and 
electrical  diagrams.  The  resulting  electrical  circuit  was 
physically  built  on  a  "brass-board"  and  tested.  If  the 


tests  proved  successful,  the  layers  representing  the  elec¬ 
trical  elements  were  manually  drawn  or  "layed-out"  on  a  grid 
that  represented  the  surface  of  the  silicon  chip.  Masks 
were  created  by  copying  the  layer  artwork  onto  a  material 
known  as  Rubylith  (a  polyester-base  covered  by  a  strippable 
red  plastic).  The  red  plastic  was  manually  removed  in  those 
areas  where  exposure  of  the  silicon  was  desired.  The  Ruby¬ 
lith  artwork  was  photo-optica  1 ly  reduced  to  produce  masks 
suitable  in  size  for  direct  contact  masking  of  the  silicon 
chip.  The  silicon  chip  was  exposed  via  a  sequential  appli¬ 
cation  of  the  masks  and  a  planar-processed  IC  resulted. 

Manual  drafting  and  Rubylith  artwork  were  the  primary 
design  tools  well  into  the  1970s  [17].  In  the  mid-1970s  the 
complexity  of  ICs  reached  a  level  that  necessitated  drastic 
changes  in  the  approaches  to  IC  design. 

There  began  a  movement  from  the  "single"  designer  ap¬ 
proach  to  a  design  team  approach.  The  design  teams  were 
composed  of  "short-fat"  engineers,  engineers  highly  special¬ 
ized  in  one  facet  of  IC  design.  A  stratified  approach  to 
design  was  initiated  and  the  teams  were  assembled  in  compa¬ 
tible  hierarchies  to  address  the  distinct  levels  associated 
with  the  design.  Large  companies  automated  some  of  the 
design  tasks  (notably  logic  minimization  and  mask  genera¬ 
tion)  and  design  automation  (DA)  became  a  major  discipline 


in  computer  science.  The  changes  were  not  without  conse¬ 
quence.  Creation  of  the  design  teams  were  accompanied  by 
the  conflicts  inherent  with  the  division  of  labor  [24], 


There  was  a  lack  of  communication  between  adjacent  design 
hierarchies  which  led  to  wasteful  iterations  of  design 
steps.  The  separation  between  chip  designer  and  system 
designer  continued.  There  was  resistance  to  the  implementa¬ 
tion  of  automated  design  aids  [17,40].  The  reluctance  to 
use  CAD  programs  was  partly  due  to  numerous  software  fail¬ 
ures  [17],  The  advancement  of  DA  was  hindered  by  proprie¬ 
tary  interests  of  companies  developing  in-house  design  aids 
[18]  . 

In  spite  of  the  problems,  IC  design  progressed  during 
the  70s  and  the  chip  complexities  grew  in  accordance  with 
“Moore's  Law".  Sophisticated  chips,  microprocessors  and 
memories,  emerged  which  found  applications  in  nearly  every 
industry.  With  the  appearance  of  the  "first"  VLSI  chip  in 
1979  came  the  realization  that  major  improvements  in  IC 
design  management  and  design  automation  techniques  were 
required.  That  realization  was  the  seed  of  the  dynamic 
change  that  characterizes  the  current  approaches  to  IC  de¬ 
sign. 

Current  Design  Approaches.  Today's  methods  of  IC 
design  are  widely  varied,  rapidly  changing,  refinements  of 
the  approaches  that  emerged  from  the  major  modifications  of 
the  mid  1970s.  Present  industrial  and  academic  approaches 
to  IC  design  incorporate  semi-automated  improvements  of 
early  IC  design  methods. 

Industrial  IC  design  is  evolving  in  a  manner  aimed  at 


minimizing  what  has  been  called  the  biggest  deterent  to  VLSI 
development  today,  non-recurring  design  costs  [6).  The 
primary  goal  of  minimizing  non-recurring  design  costs  is  but 
one  of  the  four  chief  goals  of  a  modern  design  team.  The 
remaining  industrial  design  team  goals  are:  1)  to  shorten 
the  product  development  cycle,  2)  to  minimize  design  risks, 
and  3)  to  produce  an  error-free  design  [6]. 

The  academic  approach  to  IC  design  does  not  radically 
differ  from  that  found  in  industry  but  the  differences  are 
worthy  of  discussion.  The  objective  of  modern  academic  IC 
design  curricula  is  to  produce  qualified  students  capable 
of:  1)  performing  VLSI-oriented  research,  and  2)  succeeding 
as  industrial  VLSI  designers  [9].  Preparation  of  students 
for  VLSI  research  environments  necessitates  the  use  of  a 
VLSI  design  approach  which  emphasizes  the  flexibility  (or 
inflexibility)  of  the  design  approach  itself.  These  stu¬ 
dents  will  be  the  people  who  produce  the  innovative  changes 
necessary  to  continue  effective  evolution  of  the  VLSI  design 
process.  Design  approaches  used  in  research-oriented  cur¬ 
ricula  may  vary,  perhaps  from  one  course  to  another.  Re¬ 
search-oriented  curricula  may  suggest  approaches  to  VLSI 
design  that  are  "risky"  in  the  industrial  sense  but  which 
may  lead  to  the  creation  of  innovative  changes  to  the  design 
process.  The  preparation  of  students  for  a  successful  in¬ 
dustrial  career  requires  curricula  with  VLSI  design  philoso¬ 
phies  which  parallel  those  found  in  industrial  VLSI  design. 
Most  curricula  contain  a  combination  of  both  approaches. 


Although  current  industrial  and  academic  VLSI  design 
approaches  differ  in  the  importance  placed  upon  specific 
design  objectives,  their  design  approaches  have  many  common¬ 
alities.  Decomposition  of  the  design  process  into  its  fun¬ 
damental  levels  of  abstraction  is  the  key  to  understanding 
the  current  design  philosophies. 

The  general  design  process  may  be  decomposed  from  many 
different  viewpoints.  One  decomposition  details  two  funda¬ 
mental  levels  or  structures  in  the  design  process:  function¬ 
al  design  and  physical  design  [17].  Another  decomposition 
identifies  five  domains  or  levels  of  abstraction:  1)  the 
architectural  level,  2)  the  organizational  level,  3)  the 
logic  level,  4)  the  geometry  level,  and  5)  the  electrical 
level  [9].  There  are  other  decompositions  [40].  The  com¬ 
monalities  of  modern  industrial  and  academic  VLSI  design 
approaches,  hence  the  current  design  philosophy,  have  been 
illustrated  below  through  the  application  of  the  various 
decomposition  schemes  to  the  design  approaches. 

A  modern  VLSI  design  task  is  usually  approached  at  two 
levels:  a  functional  design  level  and  a  physical  design 
level.  The  design  team  approach  is  used  both  by  industry 
and  academic  institutions.  It  is  not  unusual  for  industry 
to  have  design  teams  at  each  level  or  several  design  teams 
within  these  levels.  The  academic  approach,  which  encour¬ 
ages  the  development  of  "tall-thin"  designers,  seems  to 
favor  a  single  design  team  spanning  both  levels.  At  each 
level,  the  design  process  is  hierarchical  in  nature.  That 


is,  design  problems  are  successively  decomposed  into  smaller 
problems  while  synthesizing  small  design  elements  into  lar¬ 
ger  functional  elements  [9].  The  decomposition  and  synthe¬ 
sis  are  iterated  until  an  acceptable  design  is  achieved. 

The  functional  design  level  includes  the  architectural 
and  logical  design  tasks.  Current  approaches  to  these  tasks 
are  essentially  manually  implemented.  The  architectural  task 
is  concerned  with:  1)  the  specification  of  system  behavior, 
2)  the  identification  of  data  and  control  flow  throughout 
the  system,  and  3)  identification  of  system-level  test  re¬ 
quirements.  The  goal  at  the  architectural  level  is  to 
provide  a  configuration  that  best  satisfies  the  specified 
behavior  [40].  The  logical  design  task  is  also  three-fold: 
1)  the  desired  system  behavior  is  translated  into  a  set  of 
primitive  building  blocks  sufficient  to  implement  the  de¬ 
sired  behavior,  2)  the  primitive  building  blocks  are  synthe¬ 
sized  into  the  largest  blocks  possible,  and  3)  the  logical 
design  is  tested  to  verify  implementation  of  the  desired 
behavior.  The  logical  design  effort  should  produce  logic 
diagrams  and/or  boolean  equations  which  implement  the  de¬ 
sired  behavior  and  whose  primitive  implementations  are 
available  using  current  VLSI  technology  [40].  In  summary, 
the  functional  design  level  should  produce  a  satisfactory 
specification  of  desired  system  behavior  and  the  logical 
means  to  implement  the  behavior  using  current  VLSI  technolo¬ 
gies  . 

Most  of  the  changes  seen  in  the  evolving  IC  design 


process  have  occurred  at  the  physical  design  level  and  were 
initiated  to  address  IC  complexities  at  the  VLSI  level.  The 
physical  design  level  includes  the  following  design  tasks: 
1)  floor  plan  development,  2)  layout  or  translation  of  the 
logical  design  blocks  into  physically  equivalent  device 
assemblies,  3)  interconnection  of  the  on-chip  devices,  4) 
topological  analysis  of  the  chip  layout,  5)  timing  and 
electrical  analysis  of  the  chip  layout,  6)  verification  that 
the  layout  implements  the  specified  logical  design,  and  7) 
translation  of  the  chip  layout  information  into  a  form 
usable  by  chip  fabrication  facilities.  Many  of  the  physical 
design  tasks  have  been  automated  or  are  supported  by  CAD 
tools.  The  physical  design  level  should  produce  the  data 
necessary  to  correctly  fabricate  an  IC  that  implements  the 
original  system  specification.  Many  contributions  have  been 
made  by  the  academic  community  at  the  physical  design  level. 
Most  of  these  contributions  have  been  in  the  development  of 
CAD  tools  to  simplify  the  various  design  tasks. 

The  design  methods  summarized  above  were  best  described 
by  M.F.  Oakes  when  he  said:  "Today's  methods  have  not  been 
designed,  they  have  evolved"  [27], 

Future  Design  Approaches.  The  future  of  VLSI  hardware 
rests  in  the  number  of  electronic  applications  where  VLSI 
offers  a  cost-effective  alternative  to  existing  electronics. 
The  number  of  future  applications  for  VLSI  hardware  will  be 
functions  of  VLSI  design  costs  (non-recurring  costs  in  par¬ 
ticular)  and  design  time  [17].  The  needed  reduction  in  VLSI 


design  costs  and  time  can  be  achieved  through  the  scientific 
DESIGN  of  a  VLSI  design  methodology. 

A  complete  characterization  of  the  ideal  VLSI  design 
methodplogy  has  yet  to  be  developed.  Many  published  works 
propose  design  methods  which  address  one  or  several  of  the 
issues  which  must  be  resolved  if  VLSI  design  is  to  meet 
future  challenges.  Many  of  the  proposed  methods  share  com¬ 
mon  components.  A  scientific  evaluation  of  the  common  com¬ 
ponents  should  lead  to  a  VLSI  design  methodology  which  will 
support  the  design  complexities  required  by  future  IC  appli¬ 
cations.  A  review  of  the  frequently  proposed  components  of 
future  VLSI  design  processes  is  provided  below. 

It  is  generally  agreed  that  future  VLSI  design  methods 
must  be  hierarchical  in  nature  and  that  future  methods  must 
approach  IC  design  from  a  system-level  viewpoint 
[4,9,17,29,40].  Another  essential  characteristic  of  the 
ideal  VLSI  design  process  is  a  well-defined  connectivity 
between  the  levels  of  design  abstraction  [4,9,18,27,29,31]. 
The  usual  approach  proposed  to  provide  the  required  connec¬ 
tivity  is  the  use  of  a  single,  centralized  database  or  data 
structure  throughout  the  entire  design  process.  A  thorough 
and  effective  design  management  technique  must  be  incorpor¬ 
ated  into  the  ideal  design  method.  A  recurring  issue  in 
proposed  VLSI  design  techniques  is  the  need  to  make  VLSI 
design  accessible  to  people  whose  skills  lie  in  disciplines 
that  either  support  or  utilize  VLSI  circuitry.  Finally, 
throughout  the  proposals  for  improvements  in  VLSI  design 


11-11 


methods,  one  component  surfaces  as  the  most  critical  and 
essential  element  of  the  ideal  VLSI  design  process: 
INTEGRATED  CAD  TOOLS  [6,12,17,18,20,22,27,28,29,34,40,41]. 
It  is  believed  that  proper  integration  of  IC  CAD  tools  will 
open  VLSI  design  to  a  broad  range  of  disciplines  that  have 
major  contributions  to  make  to  future  VLSI  development.  An 
integrated  set  of  CAD  tools,  sharing  a  common  database,  will 
provide  the  inter-level  connectivity  and  design  management 
capability  essential  for  the  success  of  future  VLSI  design 
efforts. 

Academic  institutions  have  long  realized  the  importance 
of  CAD  tools  to  successful  IC  design.  Consequently,  many, 
if  not  most,  of  the  IC  CAD  tools  in  use  today  were  developed 
in  the  academic  arena.  The  academic  CAD  tools  are  freely 
shared  and  improvements  are  nearly  continuous.  Carver  Mead, 
a  pioneer  in  the  development  of  IC  CAD  tools,  believes  much 
of  the  thrust  for  new  innovation  in  VLSI  design  is  coming 
from  the  universities  [22].  Thus,  it  seems  appropriate  that 
the  universities  should  address  and  meet  the  CAD  tool  inte¬ 
gration  challenge. 

Summary  A  chronology  of  VLSI  evolution  has  been  presented 
to  develop  an  appreciation  of  the  effort  expended  to  reach 
production  of  the  first  VLSI  chip.  A  summary  of  past  and 
present  IC  design  methods  was  provided  to  demonstrate  the 
slow  evolution  of  the  IC  design  process  from  a  single¬ 
designer,  manual  effort  to  a  team-oriented,  partially  auto- 
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mated  approach.  The  essential  elements  of  future  VLSI  de¬ 
sign  methodologies  have  been  examined  and  the  need  for 
integrated  VLSI  CAD  tools  is  proposed  as  the  most  critical 
and  essential  of  all  the  required  elements.  This  thesis 
addresses  the  need  for  integrated  VLSI  CAD  tools  and  will 
provide  one  systematic,  perhaps  scientific,  method  to  inte¬ 
grate  the  tools. 


ii' 


III.  General  Characteristics  of  a  VLSI  CAD  Toolkit 

Introduction 

The  importance  of  VLSI  circuitry  to  the  DOD  has  been 
established.  It  has  been  shown  that  the  design  methodolo¬ 
gies  used  to  implement  SSI,  MSI,  and  LSI  designs  are  not 
sufficient  to  meet  VLSI  design  requirements.  A  review  of 
current  literature  indicated  that  the  emerging  VLSI  design 
methodology  will  emphasize  automation  of  design  tasks  and 
that  improved  CAD  tools  are  critically  important  to  the 
success  of  future  VLSI  design  tasks.  Access  to  VLSI  design 
for  people  with  wide  variations  in  technical  backgrounds  and 
increased  designer  productivity  were  stated  as  the  primary 
goals  of  VLSI  CAD  tool  development.  Integration  of  VLSI  CAD 
tools  into  a  single  toolkit  was  identified  as  a  central 
task  in  the  development  of  a  VLSI  design  methodology  that 
will  meet  academic  requirements. 

This  chapter  describes  the  general  properties  and  char¬ 
acteristics  of  an  integrated,  academically-oriented,  VLSI 
CAD  toolkit  and  its  components.  Also,  a  typical  design 
session  using  the  toolkit  is  outlined.  The  toolkit  de¬ 
scribed  below  and  in  subsequent  chapters  is  not  the  ultimate 
VLSI  CAD  toolkit.  The  intention  here  is  to  develop  a  basis 
for  systematic  CAD  tool  integration  with  emphasis  placed 
upon  academic  requirements. 


Ge ne r a_l  Properties  of  VLS_I  CAD  Toolkits  and  Toolkit 
Components 


Throughout  the  remainder  of  this  section,  references  to 
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a  VLSI  CAD  toolkit  are  also  references  to  individual  toolkit 


components . 

A  VLSI  CAD  toolkit  must  be  useful,  complete,  and  main¬ 
tainable.  These  toolkit  properties  are  examined  below. 

A  Useful  VLSI  CAD  Toolkit/ Toolkit  Component.  A  VLSI 
CAD  toolkit  may  be  considered  useful  if  it  possesses  the 
following  characteristics: 

1.  The  toolkit's  capabilities,  limitations,  input 
formats,  output  formats,  and  command  syntax  are 
easy  to  learn. 

2.  The  toolkit  is  easy  to  select  and  execute. 

3.  The  toolkit  is  easy  to  install  on  the  host 
computer  system. 

4.  The  toolkit  substantially  increases  the  pro¬ 
ductivity  of  the  user. 

5.  The  toolkit  effectively  uses  design  resources. 

6.  The  toolkit  makes  incompatibilities  in  subor¬ 
dinate  components  transparent  to  the  user. 

7.  The  toolkit  provides  a  mechanism  to  control 
design  information,  correctness,  and  security. 

8.  The  toolkit  can  be  used  effectively  by  people 
with  wide  variations  in  design  abilities  and  tech¬ 
nical  expertise. 

A  Complete  VLSI  CAD  Toolkit.  The  VLSI  design  method¬ 
ology  reviewed  in  chapter  2  was  decomposed  into  two  funda¬ 
mental  design  levels:  a  functional  level  and  a  physical 
level.  The  functional  and  physical  levels  were  further 
decomposed  into  several,  sub-ordinate  design  levels.  A 
complete  VLSI  CAD  toolkit  possesses  the  characteristics  of  a 
useful  toolkit  at  each  level  of  design. 

A  Maintainable  VLSI  CAD  Toolkit.  A  maintainable  VLSI 
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CAD  toolkit  is  one  which  includes  mechanisms  to  prevent 
degradations  in  the  toolkit  usefulness  and  completeness.  In 
particular,  a  VLSI  CAD  toolkit  is  maintainable  if  it  posses¬ 
ses  the  following  characteristics: 

1.  Additional  tools/features  may  be  easily  added. 

2.  Component  tools/features  may  be  easily  modi¬ 
fied  without  changing  the  fundamental  toolkit 
structure . 

3.  Toolkit  documentation  contains  the  following 
information: 

a.  Documented  source  code. 

b.  Diagrams  that  depict  the  overall  struc¬ 
ture  of  the  toolkit. 

c.  Diagrams  that  depict  the  flow  of  informa¬ 
tion  through  the  toolkit. 

d.  Diagrams  that  depict  the  flow  of  control 
through  the  toolkit. 

e.  Implementation  specific  information  con¬ 
cerning  the  toolkit. 

5.  Toolkit  documentation  may  be  easily  updated, 
reproduced,  and  distributed. 

6.  The  toolkit  is  transportable  between  similar 
computer  systems. 

7.  Test  cases  and  examples  sufficient  to  demon¬ 
strate  both  the  operation  of  the  toolkit  and  the 
tasks  necessary  to  perform  all  maintenance  opera¬ 
tions  . 


General  Organization  of  a  VLSI  CAD  Toolkit 

The  VLSI  CAD  toolkit  organization  presented  below  rep¬ 
resents  a  toolkit  configuration  which  is  useful,  complete, 
and  maintainable. 

One  way  to  describe  the  organization  of  a  VLSI  CAD 


1-3 


toolkit  is  to  develop  an  analogy  between  a  VLSI  CAD  toolkit 
and  toolkits  commonly  found  in  modern  workshops. 

A  toolkit  may  be  represented  as  a  collection  of  draw¬ 
ers,  each  of  which  contains  tools  useful  for  a  particular 
task  or  a  group  of  closely  related  tasks.  Access  to  the 
drawers  and  their  contents  is  controlled  by  a  toolkit  custo¬ 
dian. 

A  VLSI  CAD  toolkit  may  be  viewed  as  a  collection  of 
VLSI  CAD  tools  which  reside  in  "drawers"  and  which  are 
controlled  by  a  single  custodian.  The  toolkit  drawers  may 
be  partitioned  into  three  groups:  1)  design  management 
tools,  2)  design  tools,  and  3)  information  storage.  Figures 
1  and  2  illustrate  such  a  toolkit  and  depict  the  custodian's 
span  of  control,  respectively.  The  contents  of  each  drawer 
partition  and  the  general  responsibilities  of  the  toolkit 
custodian  are  described  below. 

The  Toolkit  Custodian.  The  custodian  of  a  VLSI  CAD 
toolkit  must: 

1.  Provide  the  only  user  interface  to  the  tool¬ 
kit. 

2.  Control  access  to  each  toolkit  drawer. 

3.  Control  access  to  each  drawer  component. 

4.  Control  the  flow  of  information  into,  within, 
and  out  of  the  toolkit. 

5.  Control  the  sequence  in  which  toolkit  drawers 
are  opened  and  closed. 

6.  Control  the  sequence  in  which  drawer  compo¬ 
nents  are  used. 

7.  Control  the  parameters  used  during  the  execu¬ 
tion  of  component  tools. 
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8.  Control  additions  and  modifications  to  the 
toolkit  drawers  and  their  components. 

Design  Management  Drawers.  The  toolkit  must  include 
drawers  containing  the  tools  necessary  to  accomplish  the 
design  management  tasks  listed  below.  [2,17] 


1.  Configuration  Management:  Management  of  the 

toolkit  structure,  operating  system  interface,  and 
component  relationships. 

2.  Data  Translation:  Translation  of  input/output 
data  into  useful  formats. 

3.  Resource  Management:  Management  of  the  tool¬ 

kit's  use  of  computer  system  resources. 

4.  Data  Analysis:  Analysis  of  data  to  ensure 

compatibility  with  user  and  toolkit  requirements. 

5.  Documentation  Management:  Management  of  de¬ 

sign  and  toolkit  documentation. 

6.  Environment  Control:  Management  of  the  user 

and  toolkit  operating  environment  during  a  design 
session. 

7.  Data  Archival:  Management  of  the  movement  of 

temporary  design  information  to  the  toolkit  perma¬ 
nent  design  storage  area. 

8.  Data  Access  Control:  Control  of  user  access 

to  the  toolkit,  its  components,  and  archived  data. 

9.  Data  Security:  Management  of  user's  ability 

to  modify  toolkit  data. 

10.  Data  Storage  Maintenance:  Control  of  the 

space  and  method  used  to  store  temporary  and  perm¬ 
anent  data. 

11.  Report  Generation:  Generation  of  reports 

concerning  toolkit  structure,  utilization,  and 
capability. 

12.  Design  Standards  Management:  Management  of 

the  structure  and  documentation  of  temporary  and 
permanent  design  information. 

13.  Design  Library  Management:  Management  of  the 
permanent  design  cells  used  by  toolkit  components. 


14.  Design  Schedule  Management:  Scheduling  aids 

for  tracking  user-established  design  milestones 
and  for  toolkit  maintenance  activities. 

Design  Tool  Drawers.  The  toolkit  must  include  drawers 

containing  the  necessary  tools  to  accomplish  the  general 

categories  of  design  tasks  listed  below. 

1.  Architectural:  System  level  design  con¬ 

siderations  . 

2.  Logic:  Translation  of  system  design  into 

logic  building  blocks. 

3.  Floorplan:  Functional  partitioning  of  IC 

surface. 

4.  Layout:  Translation  of  logic  blocks  into  de¬ 

vices  . 

5.  Interconnection:  Connection  of  devices. 


6.  Topological  Analysis:  Analysis  of  device  lay¬ 
out  and  interconnection  scheme  to  ensure  compati¬ 
bility  with  fabrication  techniques. 

7.  Extraction:  Extracting  device  information  for 
use  by  other  analysis  tools. 

8.  Timing  Analysis:  Analysis  of  on-chip  signal 
timing  relationships. 

9.  Electrical  Analysis:  Analysis  of  individual 
device  electrical  characteristics  as  well  as  sys¬ 
tem  level  electrical  characteristics. 

10.  Mask  Data  Generation:  Conversion  of  layout 
and  interconnection  data  to  data  usable  by  auto¬ 
mated  fabrication  equipment. 

11.  Design  Verification:  Verification  at  each 
design  level  that  the  implementation  meets  the 
design  specification  at  the  previous  level. 

12.  Design  Presentation:  Presentation  of  the 
design  in  a  format  (usually  graphical)  easily 
interpreted  visually. 

13.  Utilities:  Accessory  tools  needed  to  accom¬ 
plish  minor  design  tasks. 
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Information  Storage  Drawers.  The  toolkit  must  include 


drawers  for  the  temporary  and  permanent  storage  of  informa¬ 
tion  in  the  categories  listed  below. 

1.  Toolkit  and  component  tool  documentation:  In¬ 
cludes  source  code,  data  and  control  flow  dia¬ 
grams,  textual  descriptions,  and  learning  aids. 

2.  Design  libraries:  These  libraries  contain 

previously  designed  devices  and  circuits  (often 
called  "cells")  which  are  common  to  many  system 
architectures.  These  cells  are  intended  to  be 
incorporated  into  a  system  design  during  the  lay¬ 
out  step. 

3.  Toolkit  utilization  statistics  and  history. 

4.  Design  schedules:  User  schedules  and  toolkit 

modification  schedules. 

5.  Design  data:  Data  produced  by  tools  at  any 

design  level  which  represents  that  level's  imple¬ 
mentation  of  the  design  specification. 

6.  Design  documentation:  Documentation  support¬ 

ing  the  design  data. 

7.  Auxiliary  data  required  by  component  tools: 

Data  needed  for  operating  system  interface,  tool- 
to-tool  interconnections,  etc. 

8.  Auxiliary  data  required  by  toolkit  custodian: 
Operating  system  parameters,  user  interface  data, 
data  access  information,  etc. 


A  Typical  Design  Session  with  an  Integrated  CAD  Toolkit 

The  functional  organization  of  the  integrated  CAD  tool¬ 
kit  described  above  may  be  illustrated  by  outlining  a  typi¬ 
cal  design  session  which  uses  the  toolkit. 

One  effective  way  to  visualize  the  design  process  is  to 
consider  the  toolkit  drawers  as  distinct  magnetic  disk  stor¬ 
age  areas  and  to  treat  any  toolkit  component  as  an  executa¬ 
ble  computer  program.  Hence,  any  reference  to  "opening  a 


drawer"  signifies  an  action  to  access  that  drawer's  storage 
area  and  any  reference  to  an  action  on  the  part  of  the 
custodian  signifies  the  execution  of  a  program  residing  in 
one  of  the  particular  "drawers". 

The  sequence  of  events  expected  to  occur  in  a  "typical" 
VLSI  design  session  are  presented  below. 

1.  The  user  requests  toolkit  access  from  the  cus¬ 
todian. 

2.  The  custodian  unlocks  the  toolkit  and  assumes 
control . 

3.  The  temporary  and  permanent  information  stor¬ 
age  drawers  are  opened. 

4.  A  temporary  toolkit  session  log  is  created  and 
placed  in  the  temporary  information  storage  draw¬ 
er.  All  further  custodian  and  toolkit  activities 
will  be  recorded  in  this  log. 

5.  The  data  access  drawer  is  opened.  All  further 
requests  for  access  to  tools  or  data  are  processed 
via  this  drawer  of  tools. 

6.  The  user's  access  authorizations  are  estab¬ 
lished. 

7.  If  the  user  is  not  authorized  access  to  the 
toolkit  then  the  toolkit  is  closed  and  locked  (see 
16  below)  otherwise  the  session  continues. 

8.  The  custodian  queries  the  user  to  obtain  the 
information  necessary  to  meet  the  user's  require¬ 
ments  for  this  session. 

9.  The  resource  management  drawer  is  opened. 

10.  The  custodian  determines  whether  or  not  the 
necessary  design  resources  are  available.  If  the 
resources  are  not  available  the  user  is  given  the 
opportunity  to  place  his  request  in  a  toolkit 
queue  for  processing  at  a  later  time  (determined 
by  the  custodian) .  If  the  user  elects  to  stop 
working  the  toolkit  is  closed  and  locked  (see  16 
below) . 

11.  If  the  necessary  design  resources  are  availa¬ 
ble  then  the  custodian  opens  the  environment  con- 
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trol  and  data  security  drawers.  The  components  of 
these  two  drawers  will  be  used  to:  1)  set  the 
resource  environment  parameters  to  match  those 
required  to  interface  with  the  user's  external 
environment  and  2)  to  identify  the  data  which  may 
be  used  and  modified  by  the  user  during  the  ses¬ 
sion. 


12.  The  data  translation  drawer  is  opened.  The 
components  of  this  drawer  will  be  used  to  process 
user-specified  input  data  and  to  process  data 
generated  by  toolkit  components  during  the  comple¬ 
tion  of  user-specified  tasks. 

13.  At  this  point  the  custodian  opens  the  appro¬ 
priate  design  tool  drawers  and  executes  the  tools 
necessary  to  accomplish  the  user-specified  tasks. 
During  this  stage  other  design  management  drawers 
may  be  opened  and  closed  as  necessary  to  ensure 
proper  management  of  the  design  and  toolkit. 

14.  The  toolkit  components  are  executed  until  the 
user-specified  tasks  are  completed  or  until  the 
custodian  identifies  a  problem. 

15.  If  a  problem  occurs/  the  custodian  will  iden¬ 
tify  the  problem  and  suggest  a  course  of  action 
for  the  user.  The  toolkit  is  then  closed  and 
locked  (see  below) . 

16.  When  the  custodian  closes  and  locks  the  tool¬ 
kit  the  user  session  history  is  concluded  and 
incorporated  into  the  toolkit  history  (maintained 
in  the  permanent  information  storage  drawer) .  All 
executing  toolkit  design  tools  are  brought  to 
graceful  terminations.  The  temporary  information 
storage  drawer  is  emptied  either  by  discarding  the 
information  stored  there  or  by  moving  the  informa¬ 
tion  to  permanent  storage  if  appropriate.  All 
toolkit  drawers  are  then  closed.  If  a  condition 
has  occurred  during  this  session  which  warrants 
the  attention  of  the  person (s)  responsible  for 
maintaining  the  toolkit,  appropriate  messages  are 
generated  (sent)  to  notify  the  responsible  per- 
son(s).  The  toolkit  is  locked  when  the  custodian 
completes  execution. 


Summary 

The  first  step  toward  the  characterization  of  a  useful 
complete,  and  maintainable  VLSI  CAD  toolkit  has  been  com 
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pleted.  The  proposed  VLSI  CAD  toolkit  was  partitioned  into 
three  sections  of  drawers:  design  management  tools,  design 
tools,  and  information  storage  drawers.  A  custodian  was 
identified  and  given  responsibility  for  the  control  and 
management  of  the  toolkit.  The  properties  and  characteris¬ 
tics  of  the  toolkit,  toolkit  components,  and  the  toolkit 
drawers  were  generally  described  and  were  illustrated  by 
outlining  a  typical  VLSI  design  session.  This  general  de¬ 
piction  of  the  VLSI  CAD  toolkit  establishes  the  basis  for 
the  development  of  a  more  specific  toolkit  characterization. 

A  more  specific  definition  of  the  VLSI  CAD  toolkit  will 
be  presented  in  the  next  chapter.  Subsequent  chapters  will 
draw  heavily  on  that  detailed  description  for  the  formula¬ 
tion  of  the  weighting  metrics  and  development  of  the  tech¬ 
nique  that  will  be  used  to  methodically  develop  a  VLSI  CAD 
toolkit  by  integrating  individual  CAD  tools. 
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IV.  Specific  Characteristics  of  a  VLSI  CAD  Toolkit 

An  integrated  VLSI  CAD  toolkit  has  been  described  as  a 
collection  of  drawers  of  tools  managed  by  a  single  custo¬ 
dian.  The  general  properties  of  a  VLSI  CAD  toolkit  and  the 
toolkit  components  have  been  discussed. 

This  chapter  completes  the  characterization  of  the 
toolkit  by  describing  the  specific  characteristics  and  capa¬ 
bilities  that  the  custodian  and  each  toolkit  drawer  must 
possess.  This  discussion  is  more  detailed  than  that  in  the 
previous  chapter  however,  the  level  of  detail  has  been 
purposely  limited  to  retain  applicability  of  this  descrip¬ 
tion  to  a  wide  selection  of  automated  design  resources. 

Detailed  Custodian  Specifications.  The  toolkit  custodian 
must  possess  the  characteristics  and  capabilities  described 
below. 


User  Interface.  The  custodian  must  be  the  only  user 
interface  to  the  toolkit.  The  user  interface  must  provide: 

1.  The  capability  to  easily  select  toolkit  com¬ 
ponents  at  any  design  level. 

2.  On-line  help  and  aid  to  the  user  at  each  deci¬ 
sion  point. 

3.  Meaningful  feedback  concerning  user  entries. 

4.  Logical,  syntactical,  and  physical  error  de¬ 
tection  as  well  as  the  ability  to  recover  from  er¬ 
rors  . 

5.  The  capability  to  select  an  interface  display 
that  matches  user  equipment. 

6.  Full  access  to  user-selectable  options  in  com- 
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ponent  tools. 


7.  The  ability  to  identify  user-selectable  data 
required  by  component  tools. 

8.  An  interface  that  is  simple  enough  to  service 
very  inexperienced  users  and  flexible  enough  to 
meet  the  demands  of  expert  users. 

9.  Selectable  levels  of  input  assistance. 

10.  Meaningful  feedback  during  the  execution  of 
toolkit  components. 

11.  Command  names  which  may  be  customized  for 
user  convenience. 

12.  The  ability  to  identify  a  file  of  commands 
which  are  to  be  executed  as  though  they  were  real¬ 
time  user  inputs. 

13.  The  ability  to  tailor  output  messages  to  in¬ 
clude  user  specified  data. 

14.  Verification  that  the  data  and  tools  nece¬ 
ssary  to  fulfill  user  requests  are  available  in 
the  toolkit. 

Access  Control .  The  custodian  must  provide  absolute 
control  of  access  to  the  toolkit,  the  toolkit  drawers,  and 
the  drawer  components.  Specifically,  the  custodian  must: 

1.  Control  access  to  the  toolkit,  individual 
drawers,  and  individual  drawer  components  on  a 
user-to-user  basis. 

2.  Verify  a  potential  user's  access  authoriza¬ 
tions  in  a  manner  that  does  not  reveal  the  method 
used  to  determine  access  nor  the  access  authoriza¬ 
tions  of  other  toolkit  users. 

3.  Provide  an  audit  trail  of  repeated  attempts  to 
access  the  toolkit  by  an  unauthorized  user. 

4.  Maintain  a  history  of  all  toolkit  sessions. 
Information  Control.  The  toolkit  custodian  must  con¬ 


trol  the  flow  of  information  into,  within,  and  out  of  the 
toolkit.  This  task  is  the  most  important  of  all  custodian 


responsibilities.  The  information  management  tasks  shown 
below  must  be  included: 


1.  Input  data  must  be  analyzed  to  ensure  that  it 
is  in  a  format  which  is  compatible  with  the  tool¬ 
kit  formats  or  in  a  format  which  is  acceptable  to 
the  data  translation  tools  available  in  the  tool¬ 
kit.  Improperly  formatted  data  must  be  rejected. 


2.  All  user  input  data  must  be  treated  as  tempor¬ 
ary  or  transient  data.  User  requests  to  add, 
delete,  or  modify  permanent  toolkit  data  must  be 
stored  by  the  custodian  for  review  by  the  per¬ 
son  (s)  responsible  for  the  toolkit  configuration. 

3.  Once  data  has  been  moved  to  permanent  storage, 
the  custodian  will  prevent  modification  of  the 
data  by  any  user  in  subsequent  design  sessions. 

4.  Once  acquired,  user  input  data  will  be  inter¬ 
nally  controlled  and  translated  as  needed  for  tool 
use. 

5.  Access  to  any  and  all  temporary  or  permanent 
data,  either  by  the  user  or  by  a  resident  tool 
will  be  controlled  by  the  custodian. 

6.  All  data  output  during  a  design  session  will 
be  delivered  via  the  custodian. 

Resource  Management.  The  custodian  must  provide  con¬ 
tinuous  management  of  design  resources  during  any  design 
session.  The  custodian  must  be  responsive  to  resource 
needs  of  other  system  users  and  is  responsible  for  the 
resource  management  tasks  described  below. 

1.  Controlling  a  queueing  system  which  will  pro¬ 
vide  user  access  to  toolkit  resources  on  a  priori¬ 
ty  basis. 

2.  Management  of  temporary  and  permanent  disk 
storage  space  required  for  toolkit  execution  and 
maintenance . 

3.  Management  of  toolkit-generated  CPU  loads. 

4.  Management  of  toolkit-generated  peripheral 


device  loads 


5.  Management  of  toolkit-generated  CPU  temporary 
memory  storage  loads. 


Detailed  Design  Tool  Drawer  Specifications.  The  toolkit 
custodian  manages  three  collections  of  toolkit  drawers.  One 
set  of  drawers,  the  design  tool  drawers,  are  used  to  perform 
the  actual  design.  The  design  tool  drawers  are  described 
below. 

Architectural  Drawer.  The  architectural  drawer  must 
contain  tools  which  enable  the  accomplishment  of  the  follow¬ 
ing  tasks: 

1.  Capture  of  the  system  functional  specifica¬ 
tion. 

2.  Creation  and  capture  of  a  hierarchical  design 
at  the  system  level.  Captured  design  data  must 
include  inputs,  outputs,  flow  of  data,  and  flow  of 
control  for  the  system  and  each  subsystem. 

3.  Storage  of  captured  design  in  a  format  compa¬ 
tible  with  the  toolkit  data  translation  tools. 

Logic  Drawer.  The  logic  drawer  must  contain  tools 

which  enable  the  accomplishment  of  the  following  tasks: 

1.  Translation  of  the  system  functional  specifi¬ 
cation  into  logic  building  blocks  which  implement 
the  desired  system  architecture  and  which  lend 
themselves  to  functional  verification  via  auto¬ 
mated  methods . 

2.  Minimization  of  the  logic  gates  within  a  logic 
building  block. 

3.  Synthesis  of  logic  building  blocks  into  the 
highest  level  blocks  compatible  with  the  system 
specification. 

4.  Storage  of  logic  block  construction  data  in  a 
format  compatible  with  the  toolkit  data  transla¬ 
tion  tools. 


Floorplan  Drawer,  The  floorplan  drawer  must  contain  the 
tools  necessary  to  accomplish  the  following  tasks  [16] : 

1.  Estimation  of  total  chip  area  required  by  each 
logic  building  block. 

2.  Estimation  of  the  total  chip  area  required  by 
the  interconnection  wiring. 

3.  Estimation  of  the  total  wire  length  required 
to  interconnect  logic  blocks. 

4.  Estimation  of  the  total  wire  length  required 
by  the  design. 

5.  Estimation  of  the  total  area  required  to  lay¬ 
out  the  design. 

6.  Assistance  with  the  placement  of  logic  blocks 
to  minimize  surface  area  requirements  and  wire 
lengths . 

7.  Assistance  in  the  placement  and  ordering  of 
pads . 

8.  Assistance  with  the  placement  of  power  and 
ground  busses. 

9.  Storage  of  the  floorplan  data  in  a  format 
compatible  with  the  toolkit  design  presentation 
tools . 

10.  Accept  logic  block  data  either  directly  or 
via  the  toolkit  data  translation  tools. 

Layout  Drawer.  The  layout  drawer  must  contain  the 
tools  necessary  to  accomplish  the  following  tasks: 

1.  The  manual  specification  and  single  or  itera¬ 
tive  placement  of  individual  wires,  individual 
devices,  and  multiple  devices  (logic  blocks  or 
cells)  through  the  use  of  symbols  and/or  a  high- 
leve 1  " language " . 

2.  Automatic  placement  of  pre-designed  logic 
blocks  or  cells. 

3.  Storage  of  the  layout  data  in  a  format  compa¬ 
tible  with  the  toolkit  data  translation  tools. 

Interconnection  Drawer.  The  interconnection  drawer 


must  contain  the  tools  necessary  to  accomplish  the  following 
tasks : 


1.  Automatic  connection  of  signal,  power,  and 
ground  paths  between  devices  and  logic  blocks. 

2.  Automatic  minimization  of  interconnection  wire 
lengths. 

3.  Assistance  in  the  relocation  of  devices  and 
logic  blocks  to  effect  minimal  wiring  lengths  and 
surface  area  requirements. 

4.  Storage  of  the  interconnection  data  in  a  for¬ 
mat  that  is  compatible  with  the  toolkit  data 
translation  tools. 

Topological  Analysis  Drawer.  The  topological  analysis 
drawer  must  contain  the  tools  necessary  to  accomplish  the 
following  tasks: 

1.  Analysis  of  device, logic  block  and  connection 
wiring  layout  to  ensure  there  are  no  violations  of 
an  externally  specified  set  of  topological  design 
rules. 

2.  Storage  of  the  analysis  data  in  a  format  that 
is  compatible  with  the  toolkit  data  translation 
tools . 

Extraction  Drawer.  The  extraction  drawer  must  contain 

the  tools  necessary  to  accomplish  the  following  tasks: 

1.  Extract  device,  logic  block,  and  wiring  de¬ 
scriptions  that  are  compatible  with  the  toolkit 
timing  analysis  and  electrical  analysis  tools. 

Timing  Analysis  Drawer.  The  timing  analysis  drawer  must 

contain  the  tools  necessary  to  accomplish  the  following 

tasks : 

1.  Perform  a  static  analysis  of  on-chip  signal 
relationships  given  an  external  description  of  the 
timing  signals. 


2.  Estimate  signal  propagation  delays  by  device, 
logic  block,  and  interconnection. 


3.  Estimate  point-to-point  signal  propagation 
delays  through  multiple  devices,  logic  blocks,  and 
interconnections . 

4.  Store  the  analysis  and  estimation  data  in  a 
format  that  is  compatible  with  the  toolkit  data 
translation  tools. 

Electrical  Analysis  Drawer.  The  electrical  analysis 
drawer  must  contain  the  tools  necessary  to  accomplish  the 
following  tasks: 

1.  Determine  the  average,  RMS,  and  peak  power 
consumption  of  the  chip. 

2.  Determine  the  voltage  and  phase  relationships 
between  nodes  on  the  chip. 

3.  Determine  the  capacitance  between  any  two 
nodes  on  the  chip. 

4.  Determine  the  frequency  response  between  any 
two  nodes  on  the  chip. 

5.  Determine  the  rise  and  fall  times  of  s  signal 
at  any  node  on  the  chip. 

6.  Store  the  analysis  data  in  a  format  that  is 
compatible  with  the  toolkit  data  translation 
tools . 

Mask  Data  Generation  Drawer.  The  mask  data  generation 
drawer  must  contain  the  tools  necessary  to  convert  the 
design  description  from  a  locally  stored  format  to  a  format 
compatible  with  automated  mask  generation  equipment. 

Design  Verification  Drawer .  The  design  verification 
drawer  must  contain  the  tools  necessary  to  accomplish  the 
following  tasks: 

1.  Verify  that  the  system  architecture  meets  all 
system  functional  specifications. 

2.  Verify  that  the  logic  design  implements  the 
system  functional  specification. 

3.  Verify  that  the  layout  implements  the  logic 


design . 


that  the  layout  meets  the  timing  re¬ 
established  in  the  system  specifica- 


4.  Verify 
quirements 
tion . 

5.  Verify  that  the  layout  meets  the  electrical 
requirements  established  in  the  system  specifica¬ 
tion. 

6.  Verify  that  the  mask  generation  data  imple¬ 
ments  the  desired  layout. 

7.  Verify  that  the  fabricated  device  implements 
the  desired  system  specification  (must  be  used  in 
conjunction  with  external  hardware) . 

Design  Presentation  Drawer.  The  design  presentation 
drawer  must  contain  the  tools  necessary  to  accomplish  the 
following  tasks: 

1.  Provide  a  real-time  graphical  representation 
of  the  design  at  any  design  level. 

2.  Provide  a  "hard-copy"  representation  of  the 
design  at  any  design  level. 

3.  Provide  a  representation  of  the  design  at  any 
design  level  which  is  transportable  to  compatible 
computers . 

Utility  Drawer.  The  utility  drawer  may  contain  tools 
to  accomplish  the  types  of  tasks  described  below. 


1.  Scale  a  completed  device,  cell,  or  design. 


Detailed  Design  Management  Drawer  Specifications  The  custo¬ 
dian  manages  past,  in-progress,  and  planned  designs  through 
the  use  of  the  design  management  drawers.  The  design  man¬ 
agement  drawers  are  described  below. 

Configuration  Drawer.  The  configuration  drawer  must 
contain  the  tools  necessary  to:  1)  manage  the  additions, 
deletions,  and  modifications  to  the  toolkit  drawers  and  2) 


manage  modifications  to  the  toolkit  custodian. 

Data  Translation  Drawer.  The  data  translation  drawer 
is  one  of  the  most  important  drawers  in  the  toolkit.  All 
translation  and  reformatting  of  data  used  by  the  toolkit  is 
performed  by  the  tools  in  this  drawer.  The  following  trans¬ 
lation  capabilities  must  be  provided: 

1.  Translation  of  design  data  input  by  the  user 
into  a  format  compatible  with  the  toolkit  data¬ 
bases  and  toolkit  component  tools. 

2.  Translation  of  tool-generated  data  to  permit 
inter-drawer  data  transfer. 

3.  Translation  of  tool-generated  data  into  for¬ 
mats  compatible  with  toolkit  databases. 

4.  Translation  of  output  data  into  a  format  se¬ 
lected  by  the  user. 

Resource  Management  Drawer.  The  resource  management 
drawer  must  contain  the  tools  necessary  to  ensure  effective 
custodial  management  of  design  resources.  The  following 
resource  management  tasks  must  be  included: 

1.  Analysis  of  temporary  and  permanent  storage 
capacities  to  ensure  user  and  tool  demands  do  not 
exceed  toolkit  allocations. 

2.  Analysis  of  CPU  usage  requirements  to  ensure 
that  user  and  tool  demands  will  not  exceed  toolkit 
CPU  allocations. 

3.  Analysis  of  temporary  and  permanent  storage 
allocations  to  remove  redundant  data. 

4.  Analysis  of  toolkit  usage  on  a  user  basis  to 
ensure  usage  does  not  exceed  the  allocations  for 
that  user. 

5.  Analysis  of  existing  resources  to  ensure  user 
and  tool  demands  can  be  met  prior  to  any  attempt 
to  meet  the  demands. 


6.  Maintenance  of  a  "queue”  to  ensure  all  users 


have  equitable  access  to  toolkit  resources. 

Data  Analysis  Drawer.  The  data  analysis  drawer  must 
contain  the  tools  necessary  to  provide  the  custodian  and 
users  with  statistics  concerning  toolkit  and  design  data. 
The  scope  of  the  analysis  capability  must  be  sufficient  for 
the  custodian  to  properly  assess  the  status  of  toolkit  data 
in  order  to  fulfill  management  functions.  The  scope  of  the 
analysis  capability  must  also  be  sufficient  to  permit  users 
to  make  decisions  at  each  design  level. 

Documentation  Management  Drawer.  The  tools  in  this 
drawer  must  provide  the  custodian  with  absolute  control  over 
the  documentation  of  designs,  drawers,  and  tools  which  are 
permanent  residents  of  the  toolkit. 

Environment  Control  Drawer.  The  environment  control 
drawer  must  contain  the  tools  necessary  to  maintain  all 
toolkit  interfaces.  This  drawer  must  include: 

1.  Toolkit-to-operating  system  interface  informa¬ 
tion  and  management  tools. 

2.  Toolkit-to-peripheral  interface  information 
and  management  tools. 

3.  Inter-drawer  interface  information  and  manage¬ 
ment  tools. 

Data  Archival  Drawer.  This  drawer  must  contain  the 
tools  necessary  to  provide  the  custodian  with  absolute  con¬ 
trol  over  the  temporary  design  data  that  is  incorporated 
into  the  permanent  toolkit  database. 

Data  Access  Control  Drawer.  This  drawer  must  provide 
the  custodian  with  the  tools  necessary  to  exercise  absolute 
control,  on  an  individual  user  basis,  to  user  access  to 


toolkit  data  and  tool  drawers. 

Data  Security  Drawer.  This  drawer  must  contain  the 
tools  necessary  for  the  custodian  to  exercise  absolute  con¬ 
trol,  on  an  individual  user  basis,  over  the  user's  ability 
to  modify  toolkit  data  either  directly,  or  indirectly 
through  the  use  of  tools. 

Data  Storage  Management  Drawer.  This  toolkit  drawer 
must  contain  the  tools  necessary  to  manage  size  and  format 
of  the  temporary  and  permanent  toolkit  design  databases. 
The  capability  to  selectively  extract  data  from  the  data¬ 
bases  must  be  provided  to  the  custodian  and  to  authorized 
users . 

Report  Generation  Drawer.  This  drawer  must  contain  the 
tools  necessary  to  generate  reports  concerning  toolkit  usage 
and  contents. 

Standards  Management  Drawer.  This  drawer  must  contain 
the  tools  necessary  to  ensure  user  input  data,  tool-gene- 
rated  data,  data  resident  in  toolkit  databases,  and  toolkit 
output  data  meet  a  predetermined  set  of  standards  concerning 
format  and  content. 

Library  Management  Drawer.  This  drawer  must  contain 
the  tools  necessary  to  manage  toolkit  libraries  of  cells 
which  are  intended  to  be  incorporated  into  future  designs. 

Schedule  Management  Drawer.  This  toolkit  drawer  must 
contain  tools  sufficient  to  permit  the  establishment  and 
tracking  of  user-created  design  schedules  and  custodian¬ 
generated  schedules.  Schedule  management  must  be  provided 
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for  single-user  designs,  multi-user  designs,  and  long  and 
short  term  custodian  schedules. 

Detailed  Information  Management  Drawer  Specifications  The 
third  set  of  drawers  used  by  the  toolkit  custodian  are  the 
information  management  drawers.  These  drawers  are  used  to 
store  the  temporary  and  permanent  information  necessary  to 
accomplish  and  manage  VLSI  designs.  A  description  of  the 
information  management  drawers  is  provided  below. 

Temporary  Storage  Drawer.  This  toolkit  drawer  will  be 
used  for  the  temporary  storage  of  data  required  by  the 
custodian  or  by  any  toolkit  drawer.  This  drawer  will  not  be 
accessible  for  storage  by  any  toolkit  user  and  will  be 
emptied  when  the  custodian  closes  the  toolkit. 

Permanent  Storage  Drawer.  This  drawer  will  be  used  for 
the  permanent  storage  of  data  required  by  the  custodian  or 
any  toolkit  drawer. 

Summary 

This  chapter  concludes  the  characterization  of  a  use¬ 
ful,  complete,  maintainable,  integrated  VLSI  CAD  toolkit. 
The  level  of  detail  in  this  characterization  has  been  pur¬ 
posely  limited  to  retain  applicability  of  this  description 
to  a  wide  spectrum  of  design  resources. 

The  need  for  a  toolkit  of  this  nature  has  been  estab¬ 
lished.  This  characterization  of  the  toolkit  as  a  collec¬ 
tion  of  drawers  managed  by  a  custodian  will  provide  the 
basis  for  development  of  a  method  to  integrate  individual 
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A  Systematic  Method  for  Integrating  VLSI  CAD  Tools 


Introduction 

Discussions  in  previous  chapters  have  established  the 
importance  of  integrated  CAD  tools  to  the  success  of  future 
VLSI  design  efforts.  A  "toolkit"  of  integrated  VLSI  CAD 
tools  was  described  as  a  collection  of  drawers  managed  by  a 
"custodian".  The  general  and  specific  characteristics  of  a 
useful,  complete,  and  maintainable  CAD  toolkit  were  present¬ 
ed.  The  definition  and  description  of  an  integrated  VLSI 
CAD  toolkit  represent  the  bulk  of  the  effort  necessary  to 
actually  achieve  such  a  toolkit.  What  remains  is  the  need 
for  a  systematic  method  to  collect,  develop  and  combine  CAD 
tools  in  such  a  manner  as  to  obtain  the  desired  toolkit 
characteristics.  The  goal  of  this  chapter  is  to  present 
that  systematic  method. 

Philosophy  of  This  Integration  Method 

This  chapter  will  present  a  general,  reasonably  flexi¬ 
ble  method  suitable  for  constructing  a  useful,  complete,  and 
maintainable  VLSI  CAD  toolkit.  It  has  been  stated  many 
times  throughout  the  course  of  this  thesis  that  emphasis 
will  be  placed  upon  academic  needs.  That  emphasis  surfaces 
during  this  development  as  a  departure  from  the  rigid  pur¬ 
suit  of  a  fully  integrated  toolkit. 

Any  pragmatic  approach  to  the  systematic  integration  of 
CAD  tools  for  academic  purposes  must  permit  the  establish¬ 


ment  of  a  lesser  goal  than  the  implementation  of  a  useful. 


complete,  and  maintainable  toolkit.  Most  academic  institu¬ 
tions  simply  do  not  possess,  and  cannot  rapidly  obtain,  the 
resources  required  to  implement  a  fully-integrated  toolkit. 
The  lack  of  resources  is  compounded  by  the  urgent  need  for 
graduates  skilled  in  VLSI  design  methods  and  tools.  The 
approach  presented  here  is  designed  to  meet  the  academic 
short-term  goal,  the  rapid  construction  of  a  usable, 
partially-integrated  toolkit,  as  well  as  the  long-term  goal 
of  implementing  a  fully-integrated  toolkit. 

The  goal  of  obtaining  a  useful,  complete,  and  maintain¬ 
able  toolkit  must  never  be  ignored  but  may  be  delayed  with 
the  reality  of  academic  requirements  and  resources  in  mind. 
The  interests  of  the  long  term  toolkit  goal  are  preserved  by 
the  requirement  that  any  components  of  a  "lesser"  toolkit 
must  be  subsets  of  the  set  needed  to  implement  a  fully 
integrated  VLSI  CAD  toolkit. 

The  integration  technique  presented  here  is  meant  to  be 
a  meaningful  guideline  for  CAD  tool  integration.  This  tech¬ 
nique  is  neither  absolute  nor  infallible  and  may  not  be 
suitable  for  each  and  every  CAD  tool  collection.  The  method 
permits,  in  fact  requires,  tailoring  and  optimization  by 
each  toolkit  architect.  The  reader  should  leave  this  chap¬ 
ter  with  a  picture  of  a  useful  integration  procedure  that 
is  receptive  to  future  refinement  and  expansion. 
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The  General  Integration  Methodolo< 


ent  feedback.  There  are  nine  general  tasks  that  must  be 
accomplished  sequentially  during  the  integration  process. 
The  first  eight  tasks  must  be  iterated  until  a  toolkit  of 
acceptable  "quality"  is  realized.  The  ninth  task,  implemen¬ 
tation  of  the  toolkit  control  mechanism  (custodian)  com¬ 
pletes  the  integration.  The  tasks  are: 

1.  Identify  a  set  of  characteristics  which  com¬ 
pletely  described  the  desired  toolkit. 

2.  Define  a  set  of  metrics  sufficient  to  measure 
the  presence  of  desired  toolkit  characteristics. 

3.  Perform  the  high-level  design  of  the  control 
mechanism  that  will  be  used  for  toolkit  management 
and  operation  (the  custodian) . 

4.  Collect  existing  CAD  tools  and  position  them 
in  their  logical  places  (drawers)  within  the  tool¬ 
kit  structure. 

5.  Identify  the  drawers  in  the  toolkit  structure 
which  have  no  components. 

6.  Complete  the  toolkit  structure  by  :  1)  obtain¬ 
ing  new  tools,  2)  creating  new  tools,  or  3)  mod¬ 
ifying  existing  tools. 

7.  Evaluate  the  toolkit  quality  as  a  function  of 
the  previously  developed  metrics. 

8.  Remove  or  modify  those  components  which  fail 
the  evaluation. 

9.  Complete  the  custodian  design  and  implement 
the  custodian. 


Toolkit  Integration  Mechanics 

The  mechanics  of  CAD  tool  integration  are  detailed 
below.  These  mechanical  steps,  when  tailored  for 


application-specific  requirements,  will  lead  to  a  useful, 
complete,  and  maintainable  VLSI  CAD  toolkit. 


Identification  of  Desired  Characteristics 


The  characteristics  established  to  describe  a  desired  tool¬ 
kit  and  any  toolkit  component  must  be  non-overlapping,  rea¬ 
sonably  exhaustive,  and  sufficient  to  permit  evaluation  [5]. 
The  characteristics  selected  must  encompass  those  necessary 
to  ensure  the  toolkit  will  be  useful,  complete,  and  main¬ 
tainable.  The  toolkit's  architect  and  users  must  realize  at 
the  outset  of  an  integration  effort  that  this  step  is  per¬ 
haps  the  most  difficult  step  of  all.  The  major  problem  is 
that  many  of  the  individual  characteristics  of  quality  are 
in  conflict:  for  example,  added  efficiency  is  obtained  at 
the  expense  of  portability,  accuracy,  understandability,  and 
maintainability;  added  accuracy  decreases  portability  due  to 
dependence  upon  the  computer  word  size;  conciseness  often 
reduces  understandability  [5J.  Users  often  have  difficulty 
in  quantifying  their  preferences  in  such  conflict  situations 


The  high  level  characteristics  of  an  integrated  VLSI 
CAD  toolkit  have  been  described  in  previous  chapters  of  this 
thesis.  Much  of  the  motivation  for  the  effort  spent  in  the 
development  of  those  characteristics  was  the  desire  to  pro¬ 
vide  a  useful  baseline  intended  to  reduce  the  effort  spent 
at  this  integration  step  by  those  who  follow.  What  remains 
is  the  need  for  the  toolkit  architect  to  define  the  charac¬ 
teristics  of  the  individual  drawer  components. 


Step  2:  Definition  of  the  Evaluation  Metrics.  An 


understanding  of  the  general  characteristics  of  evaluation 


metrics  is  necessary  if  the  rapid  development  of  useful 
metrics  is  to  be  accompl ished.  Several  important  metric 
characteristics  were  summarized  in  a  recent  study  concerning 
the  evaluation  of  software  quality  [5],  Among  those  charac¬ 
teristics  were: 

1.  There  is  no  single  metric  which  can  give  a 
universally  useful  rating  of  software  quality. 

2.  One  is  generally  interested  in  where  and  how 
rather  than  how  often  a  product  is  deficient. 
Therefore  the  most  valuable  metrics  are  those 
which  flag  deficiencies  and  anomalies  rather  than 
just  producing  numbers. 

3.  For  all  simple  quantitative  metric  formulas, 
it  is  easy  to  find  counter-examples  which  chal¬ 
lenge  their  credibility. 

4.  The  software  field  is  developing  too  rapidly 
to  establish  metrics  in  some  areas. 

5.  At  best,  a  prospective  (metric)  user  could 
receive  a  useful  rating  system  by  furnishing  the 
quality  rating  system  with  a  thorough  set  of 
checklists  and  priorities. 

6.  Since  metrics  are  not  exhaustive,  the  overall 
rating  obtained  using  them  would  be  more  sugges¬ 
tive  rather  than  conclusive  or  prescriptive. 

Some  readers  may  interpret  the  metric  characteristics 
presented  above  as  indicators  of  the  uselessness  of  software 
metrics.  Metrics,  with  all  their  limitations,  provide  the 
only  means  available  to  practically  and  methodically  eval¬ 
uate  software.  A  careful  consideration  of  the  metric  char¬ 
acteristics  listed  above  should  help  explain  and  prevent 
much  of  the  indecisiveness  associated  with  attempts  to  quan¬ 
titatively  identify  what  is  "best".  The  metric  definition 
technique  presented  below  is  intended  to  identify  software 
products  (tools)  that  are  "probably  most  suitable". 


Specific  CAD  Tool  Metric  Characteristics 


metric  developed  to  measure  a  toolkit  component  must  possess 

three  fundamental  characteristics:  1)  The  metric  must  re¬ 
flect  the  essentiality  of  the  characteristic  to  the  success¬ 
ful  integration  of  the  toolkit  (essentiality  value  :  EV)  , 
2)  The  metric  must  reflect  the  "level"  to  which  the  de¬ 
sired  characteristic  is  present  while  simultaneously  signal¬ 
ling  the  presence  of  anomalies  or  deficiencies  (characteris¬ 
tic  level:  CL),  and  3)  The  metric  must  be  easy  to  compute. 
These  characteristics  provide  the  guidelines  necessary  to 
construct  the  metric  scales  and  formulas  that  will  be  used 
to  compute  numeric  indicators  of  the  "quality"  of  a  toolkit 
component. 

Metric  Scales  The  scales  shown  below  provide  a 
range  of  values  sufficient  to  identify  the  essentiality  of  a 
toolkit  component  and  to  indicate  the  degree  to  which  a 
component  possesses  a  desired  characteristic. 

The  scale  shown  below  provides  a  measure  of  the 
essentiality  of  a  characteristic  to  the  success  of  toolkit 
integration.  A  non-linear,  increasing  scale  will  place 
emphasis  on  the  more  essential  characteristics.  Although 
many  other  scales  may  have  been  constructed,  it  is  believed 
that  this  scale  is  sufficient  for  the  purposes  of  this 
thesis . 


Essentiality 
Value  (EV) 


Essentiality  of  Characteristic 
To  Successful  Integration 


Extremely  important  to  success 
(Certain  failure  if  missing) 
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Important  to  success 
(Probable  failure  if  missing) 


8  Fairly  important  to  success 

(Possible  failure  if  missing) 

2  Has  some  impact  upon  success 

(No  predictable  impact  upon 
success  if  missing  but  less 
than  optimum  integration  is 
probable) 

1  Slight  impact  upon  success 

(No  predictable  impact  upon 
success  if  missing  but  less 
than  optimum  integration  is 
certain) 


The  scale  shown  below  provides  a  measure  of  the 
presence  of  a  desired  characteristic.  The  negative  values 
were  included  to  provide  a  "penalty"  for  anomalities  and 
deficiencies . 


Characteristic 
Level  (CL) 


3 

2 

1 

0 

-1 


Degree  to  Which  Characteristic 
is  Present  in  this  Component 

The  desired  characteristic  is 
entirely  present. 

The  desired  characteristic  is 
mostly  present. 

The  desired  characteristic  is 
somewhat  present. 

The  desired  characteristic  is 
completely  absent. 

Characteristics  are  present 
which  are  somewhat  detrimental 


-2  Characteristics  are  present 

which  are  very  detrimental 

-3  Characteristics  are  present 

which  are  unacceptable 


The  Metric  Formulas  The  formulas  presented  below 


are  designed  to  compute  numeric  values  which  will  be  used  as 
indicators  of  the  relative  quality  of  the  toolkit,  any 
toolkit  drawer,  and  each  of  the  drawer  components. 


The  overall  quality  of  any  component,  drawer,  or  the 
toolkit  is  defined  by  these  formulas.  The  formulas  will  be 
used  during  the  evaluation  step  detailed  in  subsequent  para¬ 
graphs  . 


Drawer  Component  Evaluation  Formula: 


DCQ 


1 


[  EV(i) 


x  CL(i)  ] 


n 


(EQ  1) 


Where  : 

DCQ  =  Drawer  Component  Quality  (overall) 

EV  =  Essentiality  Value  of  characteristic 
i 

CL  =  Characteristic  Level  of 
characteristic  i 

n  =  Number  of  characteristics  being 
evaluated 


Drawer  Evaluation  Formula: 


DQ 


i 


£ 


I  EV(i) 


x  DCQ(i)  ] 


n 


(EQ  2) 


Where  : 

DQ  =  Drawer  Quality  (overall) 

DCQ  =  Drawer  Component  Quality  of  drawer 
component  i 


ni  ■  j  «  s  ^  :»  v 


EV  =  Essentiality  Value  of  drawer 
component  i 

n  =  Number  of  drawer  components 
Toolkit  Evaluation  Formula: 


TQ 


I  EV(i)  x  DQ(i)  ] 


n 


(EQ  3) 


Where  : 

TQ  =  Toolkit  Quality  (overall) 

DQ  =  Drawer  Quality  of  drawer  i 
EV  =  Essentiality  Value  of  drawer  i 
n  =  Number  of  drawers 


Step  3:  High-Level  Custodian  Design  The  design 
of  the  toolkit  custodian  must  be  accomplished  in  a  hier¬ 
archical  fashion.  At  this  level  the  design  is  concerned 
with  the  custodian  architecture  and  with  the  flow  of  control 
and  data  within  the  toolkit.  The  design  should  be  document¬ 
ed  using  a  combination  of  text  and  charts  which  clearly 
indicate  the  flow  of  data  and  control.  Use  of  the  Struc¬ 
tured  Analysis  and  Design  Technique  (SADT)  technique  (devel¬ 
oped  by  SofTech  Corp.)  is  highly  recommended. 

Care  must  be  taken  during  this  level  of  design  to 
ensure  the  design  is  implementation  independent.  The  design 
documentation  should  be  sufficiently  detailed  to  enable  the 
toolkit  architect  to  clearly  illustrate  the  toolkit  struc¬ 
ture  to  potential  users  and  those  tasked  to  implement  the 
toolkit. 


The  custodian  design  should  be  performed  with  a 


constant  awareness  of  the  desired  characteristics  and  con¬ 


tinuous  reference  to  the  evaluation  metrics  which  have  been 
previously  established  for  those  characteristics. 

A  representative  high  level  custodian  design# 
based  upon  the  characteristics  described  in  previous  chap¬ 
ters,  has  been  performed  and  is  included  as  Appendix  A  to 
this  thesis. 

Step  4:  Collect  Existing  CAD  Tools  At  this  step 
in  the  integration  process,  all  existing  CAD  tools  which 
appear  to  have  a  useful  place  in  the  VLSI  CAD  toolkit  are 
collected  and  placed  in  appropriate  drawers.  It  is  possible 
that  a  versatile  CAD  tool  may  fit  into  one  or  more  drawers 
and  should  be  so  placed.  Caution  should  be  observed  when 
evaluating  a  single  tool  appearing  in  multiple  drawers  to 
ensure  that  only  those  features  of  the  tool  which  are  perti¬ 
nent  to  its  CURRENT  drawer  are  evaluated.  The  best  approach 
is  to  place  a  tool  in  a  drawer  even  though  its  usefulness  is 
questionable.  The  tool  will  be  eliminated  during  evaluation 
if  it  is  of  no  real  value. 

An  example  of  this  step  has  been  performed  using 
the  CAD  tools  currently  available  to  AFIT.  The  distribution 
is  provided  as  appendix  B  to  this  thesis. 

Step  5:  Identify  Empty  Toolkit  Drawers  Identifi¬ 
cation  of  empty  toolkit  drawers  is  the  easiest  step  in  the 
integration  process.  Filling  the  empty  drawers  may  be  one 
of  the  more  time-consuming  steps. 

Step  6 ;  Complete  the  Toolkit  Structure  During 
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this  step,  empty  toolkit  drawers  are  filled  in  one  of  the 
following  manners:  1)  Obtaining  new  tools,  2)  Creating  new 
tools,  or  3)  Modifying  existing  tools. 

This  is  the  first  decision  point  concerning  wheth¬ 
er  or  not  to  pursue  the  implementation  of  a  fully  integrated 
toolkit.  It  is  believed  that  most  academic  institutions 
will  not  have  sufficient  resources  to  complete  the  toolkit 
the  first  time  integration  is  performed.  At  this  point,  the 
goal  may  be  reduced  to  creating  a  toolkit  which  is  immedi¬ 
ately  usable.  If  a  fully  integrated  toolkit  is  not  desired 
or  possible  immediately,  then  complete  only  those  drawers 
necessary  to  make  the  toolkit  usable.  The  empty  drawers 
should  be  marked  for  completion  at  a  later  date  (perhaps 
during  subsequent  courses  or  thesis  activity).  The  next 
decision  point  of  similar  consequence  occurs  during  the 
evaluation  step. 

If  a  fully  integrated  toolkit  is  immediately  re¬ 
quired  then  the  drawers  must  be  filled  before  proceeding. 
The  first  step  in  the  process  to  complete  the  drawers  should 
be  a  careful  re-examination  of  the  existing  tools.  Perhaps 
a  tool  possessing  the  necessary  characteristics  has  been 
overlooked.  Check  all  other  drawer  components.  Local  crea¬ 
tion  of  new  tools  has  a  high  probability  of  success  (since 
the  desired  characteristics  and  evaluation  criteria  are 
known).  However,  software  creation  is  a  time-consuming  and 
laborious  process  requiring  proper  resources.  Obtaining 
(purchasing)  additional  tools  is  the  final  option.  If  pos- 


sible,  purchase  contracts  should  include  the  desired  charac¬ 
teristics  and  the  evaluation  metrics  as  a  formal  part  of  the 
component  specification. 


Step  7:  Toolkit  Evaluation  The  toolkit  evalua¬ 

tion  is  a  critical  step  in  the  integration  process.  The 
evaluation  should  be  accomplished  by  those  responsible  for 
the  toolkit  implementation,  those  responsible  for  toolkit 
maintenance  and  by  as  many  of  the  potential  users  as  possi¬ 
ble.  The  evaluation  should  be  performed  under  the  guidance 
of  the  single  person  or  group  that  has  the  overall  responsi¬ 
bility  for  the  toolkit.  The  person  or  group  that  has  the 
overall  toolkit  responsibility  must  be  the  final  authority 
in  all  decisions  concerning  the  toolkit. 

The  evaluation  process  is  a  six-stage  process 
consisting  of: 

1.  Assigning  essentiality  values  (EV)  to 
each  desired  characteristic  of  the  drawer 
components,  drawers,  and  the  toolkit. 

2.  Determining  characteristic  level  values 
(CL)  for  each  drawer  component. 

3.  Computing  the  drawer  component  quality 
value  (DCQ)  for  each  of  the  drawers. 

4.  Computing  the  drawer  quality  value  (DQ) 
for  each  of  the  drawers. 

5.  Computing  the  toolkit  quality  value  (TQ) 
for  the  toolkit. 

6.  Determining  if  the  toolkit  quality  value 
(TQ)  is  acceptable. 

The  second  decision  point  concerning  whether  or 
not  to  pursue  a  fully  integrated  toolkit  occurs  when  the 
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toolkit  quality  value  is  examined.  Acceptance  of  a  less- 
than-optimum"  toolkit  is  an  alternative  available  to  those 
who  wish  to  have  a  usable  toolkit  immediately  available  even 
though  the  toolkit  is  not  complete  or  maintainable.  A 
realistic  view  of  the  current  state  of  most  academic  insti¬ 
tutions  indicates  this  may  be  the  case. 

If  the  decision  is  made  to  accept  a  toolkit  which 
is  not  fully  integrated,  then  a  commitment  must  be  made  to 
vigorously  pursue  complete  integration.  Although  a  partial¬ 
ly  integrated,  controlled  set  of  CAD  tools  is  preferable  to 
unorganized  tools,  the  goals  stated  early  in  this  thesis 
cannot  be  achieved  without  a  useful,  complete,  and  maintain¬ 
able  VLSI  CAD  toolkit. 

An  example  of  the  evaluation  process,  an  evalua¬ 
tion  of  a  sample  custodian  constructed  for  use  at  AFIT 
(contained  in  appendix  C) ,  is  included  as  appendix  D  to  this 


thesis . 


Step  8:  Remove  or  Modify  Components  The  decision 


to  remove  or  modify  those  components  which  fail  evaluation 
must  be  the  responsibility  of  those  tasked  to  implement  the 
toolkit.  Removal  of  components  necessitates  a  reiteration 
of  the  integration  process.  Modification  of  a  component  or 
components  necessitates  only  a  reiteration  of  the  evaluation 


step. 


9:  Completion  of  the  Custodian  Completion 


of  the  custodian  is  necessarily  the  last  step  in  the  inte¬ 
gration  process.  At  this  point  in  the  process  all  other 


toolkit  components  have  been  favorably  evaluated.  The  cus¬ 
todian  will  provide  the  control  and  cohesion  necessary  to 
make  the  toolkit  function  as  a  single  entity. 


During  this  step  the  high-level  design  of  the 
custodian  is  reviewed  and  corrected  to  correlate  with  the 
toolkit  structure  remaining  after  the  last  evaluation. 
Next,  the  high-level  custodian  design  is  implemented  using 
an  available  language.  Preference  should  be  given  to  high- 
level  languages  and  to  languages  which  enforce  structured 
programming  techniques  since  they  are  more  likely  to  enable 
the  creation  of  maintainable  software. 

A  sample  custodian,  written  in  the  UNIX  "C  Shell" 
language,  is  provided  as  appendix  C  to  this  thesis. 

Summary 

The  mechanics  of  CAD  tool  integration  have  been  pre¬ 
sented.  The  nine-step  method  has  been  proposed  which  repre¬ 
sents  a  general  but  flexible  way  to  implement  the  type  of 
toolkit  specified  in  previous  chapters.  A  set  of  metrics 
has  been  presented  which  will  provide  a  satisfactory  way  to 
systematically  rate  the  toolkit  and  its  components.  The 
reader  was  shown  the  decision  points  where  the  integration 
method  permits  the  user  to  postpone  full  integration  to 
obtain  a  partially-integrated  but  usable  collection  of 
tools . 

In  the  interest  of  improving  the  readability  of  this 
work,  several  examples,  intended  to  illustrate  the  integra- 


tion  process  steps  have  been  moved  to  the  appendices.  These 
examples  are  essential  elements  of  this  work  and  must  not  be 
overlooked  or  excluded  if  the  reader  is  to  obtain  a  full 
understanding  of  the  VLSI  CAD  tool  integration  process. 

The  next  chapter  will  provide  a  discussion  of  the  work 
done  to  create  the  examples  contained  in  the  appendices  and 
should  serve  as  a  first-level  evaluation  of  the  validity  of 
the  methods  suggested  herein.  The  final  chapter  will  sum¬ 
marize  this  author's  work  and  will  include  recommendations 
for  future  work. 
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VI .  Discussion  of  the  Prototype  Implementation 
Introduction 

The  inability  to  optimize  time-limited,  VLSI-oriented 
academic  curricula  has  been  identified  as  a  problem  which 
seriously  hinders  the  education  and  production  of  the  types 
of  engineers  that  will  be  required  to  meet  future  VLSI 
design  challenges.  The  background  surrounding  this  problem 
has  been  presented  in  Chapters  1  and  2  of  this  thesis.  The 
availability  of  an  integrated,  technically-complete,  academ¬ 
ically-oriented  VLSI  CAD  toolkit  has  been  identified  as  a 
possible  solution  to  the  optimization  problem.  Chapters  3 
and  4  have  presented  the  general  and  specific  characteris¬ 
tics  of  the  required  toolkit.  Chapter  5  detailed  a  systema¬ 
tic  method  and  a  set  of  CAD  tool  evaluation  metrics  proposed 
as  sufficient  to  implement  an  integrated  VLSI  CAD  toolkit. 

An  effort  has  been  made  to  evaluate  the  proposed  tool¬ 
kit  structure  and  the  integration  methodology  through  the 
implementation  of  a  prototype  toolkit  structure  and  its 
custodian.  The  details  of  the  prototype  implementation  have 
been  provided  as  appendices  A,  B,  C,  and  D.  This  chapter 
presents  a  discussion  of  the  prototype  effort. 

The  appendices  have  been  provided  to  serve  two  pur¬ 
poses:  1)  to  illustrate  the  proposed  toolkit  structure  and 
integration  methodology  and  2)  to  provide  enough  information 
to  enable  a  rudimentary  evaluation  of  the  utility  of  the 
toolkit  structure  and  the  integration  methodology.  The 


appendices  will  be  discussed  in  their  order  of  appearance 


which  has  been  arranged  to  follow  the  actual  sequence  of 
steps  used  during  the  construction  of  the  prototype  toolkit. 


High-Level  Design  of  the  Toolkit  Custodian 


The  high-level  design  of  the  toolkit  custodian  is  pre¬ 
sented  as  appendix  A. 

Goal.  The  goal  of  the  work  presented  in  this  appendix 
was  the  illustration  of  the  technique  and  documentation 
required  during  the  functional  requirements  analysis  phase 
of  any  high-level  design  of  a  VLSI  CAD  toolkit  custodian 
program. 

Contents.  This  appendix  contains  the  products  of  a 
partial,  high-level  design  of  a  prototype  toolkit  custodian. 
The  design  was  accomplished  using  the  Structured  Analysis 
and  Design  Technique  (SADT).  The  SADT  technique  is  the 
recommended  design  technique  and  the  products  provided  in 
this  appendix  illustrate  those  required  at  this  design 
level.  The  products  provided  include:  1)  SADT  diagrams  and 
the  necessary  accompanying  text  pages,  2)  a  node  index,  and 
3)  a  data  dictionary.  The  reader  is  alerted  to  an  unusual 
page  numbering  method  employed  in  thi;  appendix.  The  pages 
containing  the  text  associated  with  the  SADT  diagrams  have 
been  numbered  on  the  front  while  the  text  has  been  provided 
on  the  reverse  side  of  the  page.  This  method  was  used  to 
ensure  the  text  and  SADT  diagrams  would  face  each  other 
(required  by  SADT  documentation  standards). 

Comments.  It  should  be  clear  that  the  high-level  de- 


sign  of  a  program  does  not  begin  and  end  with  the  products 
provided  in  this  appendix.  The  design  begins  with  a  clear 
statement  of  requirements  which  are  completely  understood 
and  agreed  upon  by  the  designer  and  the  originators  of  the 
requirements.  The  requirements  for  this  design  were  ex¬ 
tracted  from  the  VLSI  CAD  toolkit  characterization  developed 
in  Chapters  3  and  4  of  this  document. 

The  SADT  technique  is  used  to  transform  user  require¬ 
ments  into  a  high-level  design  which  clearly  depicts  the 
design  structure  and  which  is  easily  analyzed  and  understood 
by  both  the  user  and  the  designer.  The  combination  of 
graphical  and  textual  materials  in  the  design  documentation 
appear  to  be  very  effective  when  used  during  design  reviews. 

The  design  documented  in  Appendix  A  is  a  partial, 
hierarchical  design  developed  only  a  few  levels  deep. 
Normally,  the  design  would  be  developed  to  a  level  of  detail 
just  above  that  which  requires  implementation-dependent 
information.  The  reader  should  observe  the  hierarchical 
nature  of  the  design  and  the  utility  of  the  SADT  method  in 
presenting  both  the  form  and  content  of  the  design. 

The  successful  completion  of  this  design  phase  is  a 
critical  milestone  in  the  toolkit  integration  process.  It 
is  at  this  level  that  the  potential  user  has  the  best  oppor¬ 
tunity  to  ensure  the  toolkit  structure  will  satisfy  require¬ 
ments.  From  the  designer/integrator  perspective,  this  de¬ 
sign  phase  affords  the  best  opportunity  to  resolve  re¬ 
quirement  and  design  conflicts.  The  SADT  documentation 


technique  also  forces  the  designer  to  develop  and  organize  a 
logical  design  approach.  The  completion  of  this  design 
phase  does  not  signal  the  end  of  the  design  task.  A  proper 
approach  to  the  design  of  the  custodian,  and  any  other  piece 
of  complex  software,  should  include  a  systems  design  phase 
and  a  detailed  design  phase. 

Although  the  systems  and  detailed  design  phases  were 
incorporated  in  the  prototype  custodian  design,  time  did  not 
permit  their  formal  documentation.  When  the  high-level 
design  was  finished,  a  prototype  toolkit  framework  and  its 
drawer  structure  were  implemented. 

Implementation  of  Toolkit  Framework  and  Drawer  Structure 

A  prototype  implementation  of  the  proposed  toolkit 
structure  and  its  "drawers"  is  presented  as  Appendix  B. 

Goal.  The  goals  of  this  portion  of  the  prototype 
effort  were  twofold:  1)  to  illustrate  one  method  of  actual¬ 
ly  implementing  the  proposed  toolkit  and  its  "drawers"  and 
2)  to  evaluate  the  practicality  of  the  proposed  structure. 

Contents.  Appendix  B  documents  the  prototype  toolkit 
structure  as  it  was  implemented  using  the  hierarchical  di¬ 
rectory  feature  of  the  AFIT  VAX  11/780  UNIX  (Bell  Laborator¬ 
ies)  operating  system.  The  toolkit  structure  is  documented 
in  four  parts:  1)  a  description  of  the  mapping  that  was 
employed  to  map  the  toolkit  drawer  names  to  UNIX  directory 


names,  2)  a  graphical  depiction  of  the  toolkit  structure 
using  the  UNIX  directory  names  assigned  to  the  toolkit 
drawers,  3)  the  source  code  for  the  UNIX  command  language 


("C  Shell")  program  which  was  used  to  created  the  toolkit 
structure  on  the  AFIT  VAX  11/780  and  4)  a  detailed  listing 
of  a  first-effort  to  distribute  existing  AFIT  VLSI  CAD  tools 
within  the  prototype  toolkit  structure. 

Comments.  The  hierarchical  directory  feature  of  UNIX 
lends  itself  nicely  to  the  implementation  of  the  suggested 
toolkit.  The  composition  and  execution  of  the  program  to 
build  the  directories  was  very  straightforward.  The  avail¬ 
ability  of  hierarchical  directories  should  not  be  viewed  as 
a  "convenient"  and  isolated  feature  available  only  to  this 
author.  The  early  and  continuing  emphasis  of  this  thesis  has 
been  to  create  an  "academically-oriented"  toolkit.  The  UNIX 
operating  system  has  found  favor  with  many  academic  institu¬ 
tions  and  certainly  with  those  interested  in  the  development 
of  VLSI  CAD  tools.  The  hierarchical  directory  feature  is 
also  emerging  in  the  new  generations  of  micro-computer  oper¬ 
ating  systems. 

The  structure  of  the  "directory-oriented"  toolkit  is 
easy  to  observe  and  understand.  Modifications  to  the  struc¬ 
ture  should  be  simple  and  easily  accomplished. 

The  distribution  of  existing  CAD  tools  proved  to  be  a 
major  task.  The  listing  provided  in  the  latter  part  of  this 
appendix  clearly  demonstrates  the  magnitude  of  the  task. 
The  tool  distribution  effort  revealed  the  need  to  identify 
several  partitions  to  the  task.  The  distribution  of  exist¬ 
ing  tools  must  be  partitioned  into  the  following  subordinate 


tasks : 


1.  The  tool  distribution  list  should  be  indepen¬ 
dently  formed  by  several  people  familiar  with  the 
capabilities  and  limitations  of  the  CAD  tools. 

This  method  should  ensure  correct  tool  distribu¬ 
tion  using  "corporate  memory"  and  should  optimize 
tool  placement  through  the  identification  of  tools 
capable  of  providing  multiple  functions. 
Assignment  of  the  distribution  task  to  an 
individual  or  a  very  limited  group  of  people 
invites  failure. 

2.  Once  the  tool  distribution  has  been  ac¬ 
complished,  the  implementation-specific  portions 
of  the  source  code  for  each  tool  must  be  modified 
to  reflect  the  new  "location"  of  the  tool  and  the 
new  "location"  of  tools  and  data  required  by  the 
tool.  This  task  must  be  accomplished  by  people 
intimately  familiar  with  the  tool's  source  code 
language,  the  support  computer  operating  system, 
and  the  tool  itself.  Although  the  requirements 
for  this  step  appear  to  be  very  demanding,  the 
necessary  expertise  may  be  found  in  most  academic 
institutions . 

The  distribution  of  the  current  AFIT  CAD  tools  has 
revealed  the  areas  or  drawers  of  the  proposed  toolkit  for 
which  there  are  no  exiting  tools.  These  drawers  are:  1) 
Configuration,  2)  Resource  Management,  3)  Environmental 
Control,  4)  Data  Access  Control,  5)  Data  Security,  6)  Report 
Generation,  7)  Standards  Management,  8)  Schedule  Manage¬ 
ment,  9)  Architectural,  10)  Floorplan,  and  11)  Interconnec¬ 
tion.  Several  iterations  of  the  distribution  process  using 
the  technique  suggested  above  will  certainly  eliminate  some 
of  the  empty  drawers.  The  lack  of  components  for  the  Stan¬ 
dards  Management  drawer  is  of  particular  significance.  The 
implementation  of  uniform  standards  for  toolkit  components 
and  data  will  require  the  development  of  a  database  struc¬ 
ture  for  design  data  (including  libraries  of  data)  and  the 
creation  of  programs  sufficient  to  manage  the  database. 
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Observation  of  the  quantity  and  diversity  of  the  VLSI 
CAD  tools  currently  available  at  AFIT  supports  the  sugges¬ 
tion  that  a  method  must  be  implemented  to  rapidly  provide 
students  with  easy  and  effective  access  to  the  tools. 

A  copy  of  the  program  used  to  build  the  prototype 
toolkit  structure  and  a  copy  of  the  distribution  listing 
have  been  placed  in  the  directory  named 
"/usr/ local/cad/ trv"  on  the  AFIT  VAX  11/780.  The  distribu¬ 
tion  listing  was  created  using  the  current,  complete  UNIX 
path  names  to  the  existing  tools.  The  intention  was  to 
facilitate  the  construction  of  a  UNIX  "C  Shell"  program 
which  could  use  the  listing  to  actually  find  and  move  the 
existing  tools  to  the  toolkit  structure. 

Custodian  Source  Code 

A  prototype  implementation  of  the  toolkit  custodian  is 
presented  in  Appendix  C. 

Goals.  The  goals  of  this  prototype  task  were:  1)  to 
illustrate  the  structure  of  a  useful  toolkit  custodian  and 
2)  to  provide  a  toolkit  drawer  which  could  be  evaluated 
using  the  methodology  and  metrics  developed  in  this  thesis. 

Contents.  Appendix  C  contains  the  source  code  for  a 
prototype  toolkit  custodian  program  written  using  the  UNIX 
"C  Shell"  command  language.  The  line  numbers  are  provided 
for  easy  reference  during  this  discussion  and  must  be  re¬ 
moved  prior  to  attempting  to  use  the  code.  A  copy  of  the 
custodian  has  been  placed  in  the  directory  named 
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"/usr/local/cad/trv"  on  the  AFIT  VAX  11/780.  Also  included 
in  the  directory  are  a  small  number  of  files  which  are 
sufficient  to  permit  a  demonstration  of  the  custodian. 
Throughout  the  remainder  of  this  section  discussions  of 
custodian  features  will  be  referenced  to  the  source  code  by 
including  the  appropriate  source  code  line  numbers  in  paren¬ 
theses  . 

Comments.  The  prototype  custodian  implements  most  of 
the  structure  presented  in  Appendix  A  as  node  "COSO".  The 
high-level  design  identifies  four  major  custodian  tasks  or 
processes.  The  prototype  incorporation  of  each  of  the  pro¬ 
cesses  is  discussed  below. 

1.  Assign  User  Access  Level  (CUS1):  This  process 
is  implemented  in  the  prototype  toolkit  through 
the  use  of  lists  stored  in  disk  files.  Three 
lists  of  UNIX  "login  names"  were  created.  Each 
list  represents  a  different  level  of  access  to  the 
toolkit.  The  lists  are  stored  in  the  "Data  Access 
Control"  drawer  (36-47).  Three  levels  of  access 
were  established  with  level  1  representing  the 
lowest  level  and  level  3  the  highest.  Level  3 
represents  the  level  of  access  which  would  be 
provided  those  responsible  for  toolkit  design  and 
maintenance.  A  user's  access  level  is  established 
early  in  the  execution  of  the  custodian  (168-227). 

The  access  level  is  used  frequently  throughout  the 
custodian  during  the  presentation  of  menus  and 
during  the  validation  of  menu  selections  (312, 

317,  322,  619,  623,  729,  753,  777,  807,  1050). 

The  access  level  is  also  used  to  determine  whether 
or  not  a  user  is  permitted  to  execute  a  particular 
toolkit  component  (373-379).  Three  lists  of  tool¬ 
kit  components  are  maintained  in  the  "Data  Access 
Control"  drawer.  The  lists  are  segregated  accord¬ 
ing  to  access  level.  List  1  contains  those  tools 
which  may  be  executed  by  users  with  access  level 
1,  list  2  contains  tools  accessible  to  users  with 
level  2  access,  etc.  Some  user  permissions  are 
verified  via  the  operating  system  (  145,  149,  478, 

520,  562,  938,  977,  1075,  1097,  1135  ). 


2.  Open  Toolkit  (CUS2)  :  This  major  process  was 
designed  using  two  subordinate  processes:  1)  open 
for  authorized  user  and  2)  record  unauthorized 
user  access  attempt.  Both  processes  were  addres¬ 
sed  in  the  prototype  custodian.  The  first  step  in 
the  "opening"  is  the  disabling  of  the  user's  abil¬ 
ity  to  interrupt  the  custodian  program  (8-13). 
The  second  step  is  the  creation  of  a  temporary  log 
of  the  session  (110-227).  During  the  creation  of 
the  session  log,  each  session  is  assigned  a  unique 
session  ID  composed  of  the  date  and  the  process  ID 
assigned  to  the  current  execution  of  the  custo¬ 
dian.  Also,  the  user  access  lists  (same  as  the 
access  level  lists  described  above)  are  scanned  to 
see  if  the  current  user  is  authorized  access.  If 
the  current  user's  "login  name"  does  not  appear  in 
any  of  the  access  lists,  then  the  attempted  access 
is  recorded  in  a  security  log  (187-192).  The  in¬ 
formation  recorded  in  the  log  identifies  the  user, 
the  time  of  the  security  violation,  and  the  ses¬ 
sion  ID.  Any  attempt  to  gain  access  by  an  unauth¬ 
orized  user  results  in  a  message  to  the  user 
advising  him  of  the  steps  necessary  to  gain  access 
authorization.  The  instructions  to  the  user  in¬ 
clude  the  name  and  location  of  the  person  respon¬ 
sible  for  toolkit  management  (199-211).  The  tool¬ 
kit  is  gracefully  closed  following  an  unauthorized 
access  attempt.  If  the  user  is  permitted  access, 
then  the  toolkit  remains  open,  user  interrupt 
capability  is  restored  (228)  (jumps  to  graceful 
close  on  interrupt) ,  and  the  user  is  presented 
with  the  first  menu  (231). 

3.  Provide  Toolkit  (CUS3) :  This  portion  of  the 
custodian  was  designed  with  four  primary  processes 
in  mind:  1)  obtain  user  input,  2)  analyze  user 
input,  3)  respond  to  user  input,  and  4)  analyze 
response.  Each  of  the  processes  above  were  incor¬ 
porated  in  the  prototype  custodian.  The  user 
input  is  obtained  primarily  as  a  response  to  a 
menu  of  options.  Six  selection  menus  are  provided 
(231-249,  291-333,  603-630,  811-824,  912-929, 
1048-1065).  The  analysis  of  a  user's  response  is 
accomplished  through  the  use  of  "case"  statements 
with  a  "default".  If  an  invalid  input  is  detec¬ 
ted,  the  default  case  statement  displays  the  con¬ 
tents  of  a  "help"  file  to  the  user.  Other  user 
inputs  are  obtained  as  needed.  The  custodian 
response  to  a  user  input  consists  of  messages  to 
the  user,  tests  for  the  existence  and  access  per¬ 
mission  to  user  requested  data,  execution  of  user 
requested  tools,  and  log  entries.  A  typical  cus¬ 
todian  response  is  shown  in  the  component  execu¬ 
tion  portion  of  the  program  (344-444).  Finally, 


the  custodian  "analyzes"  a  component  execution 
response  by  displaying  the  status  code  assigned  to 
the  execution  by  the  operating  system.  The  status 
code  is  shown  to  the  user  and  is  also  stored  in 
the  toolkit  log  (398). 

4.  Close  Toolkit  (CUS4) :  The  prototype  custodian 
includes  the  necessary  steps  to  "gracefully"  close 
the  toolkit  (1180-1247).  The  beginning  of  the 
"closing"  is  identified  by  a  program  label 
(close_kit).  This  label  is  the  re-entry  point  in 
the  custodian  immediately  following  a  user  attempt 
to  interrupt  custodian  execution.  The  closing 
process  performs  4  steps:  1)  Temporary  storage 
space  used  by  this  user  session  is  cleared  (1228- 
1232),  2)  the  toolkit  management  data  is  updated 
(1193-1223),  3)  the  temporary  session  log  that  was 
created  for  this  user  session  is  appended  to  the 
permanent  toolkit  history  log  (1226),  and  4)  the 
user  is  notified  that  the  toolkit  is  closed  and 
also  of  any  processes  that  remain  in  execution  as 
a  result  of  this  user  session  (1237-1244). 

The  custodian  program,  implemented  in  the  UNIX  "C 
Shell"  is  rather  limited  since  the  implementation  language 
does  not  permit  the  use  of  "structured"  programming  tech¬ 
niques.  The  structure  and  content  of  the  prototype  custo¬ 
dian  may  be  converted  to  a  more  powerful  language  (eg.  "C"). 
The  prototype  custodian  is  comprehensive  enough  to  demon¬ 
strate  its  flexibility  and  utility  and  is  complex  enough  to 
evaluate  using  the  evaluation  methodology  and  metric  pro¬ 
posed  as  part  of  this  thesis. 


Evaluation  of  the  Prototype  Custodian 

An  evaluation  of  the  prototype  custodian  is  presented 
as  appendix  D. 

Goals.  The  goals  of  this  evaluation  are  to  illustrate 
the  evaluation  of  a  typical  toolkit  drawer  or  drawer  compo¬ 
nent  and  to  test  the  utility  of  the  evaluation  metrics  and 
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formulas . 


Contents.  Appendix  D  contains  a  review  of  the  evalua¬ 
tion  metrics  and  formulas  that  were  developed  in  Chapter  5. 
The  appendix  also  contains  an  evaluation  of  the  prototype 
custodian  described  above.  The  component  descriptions  and 
desired  characteristics  that  were  used  during  the  evaluation 
are  based  upon  the  custodian  characteristics  presented  in 
Chapters  3  and  4.  In  this  case,  the  toolkit  drawer  being 
evaluated  is  the  custodian  and  the  drawer  components  are  the 
desired  custodian  characteristics.  In  the  general  case,  the 
drawer  being  evaluated  could  be  any  toolkit  drawer  and  the 
components  would  be  the  individual  contents  of  the  drawer 
(eg.  programs).  This  evaluation  method  may  also  be  applied 
to  the  drawer  components  themselves. 

Comments.  The  evaluation  presented  in  this  appendix  is 
admittedly  biased.  A  strong  effort  has  been  made  to  reduce 
the  effects  of  the  bias  so  they  have  an  insignificant  effect 
upon  the  general  outcome  of  the  evaluation.  The  application 
of  the  evaluation  metrics  to  the  custodian  was  relatively 
simple.  Perhaps  the  simplicity  of  the  evaluation  is  due  to 
the  fact  that  only  a  single  person  was  involved  and  that 
person  was  very  familiar  with  the  component  being  evaluated. 

The  evaluation  was  conducted  in  three  steps:  1)  es¬ 
sentiality  values  (EV)  or  "priorities"  were  assigned  to  each 
desired  component  characteristic,  2)  the  prototype  custodian 
was  examined  and  a  characteristic  level  (CL)  or  "presence" 
level  was  assigned  to  each  characteristic,  3)  the  evaluation 
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formulas  were  applied. 

A  summary  of  the  component  ratings  is  presented  on  page 
D-19.  The  summary  provides  a  means  of  comparison  between 
the  maximum  attainable  ratings  (calculated  by  assigning  the 
characteristic  level  "3"  to  each  characteristic  being  rated) 
and  the  ratings  actually  obtained.  The  results  of  the 
evaluation  are  encouraging.  Two  useful  measures  emerged 
from  the  evaluation:  1)  an  absolute  measure  of  the 

strengths  and  weaknesses  of  the  component  and  2)  a  relative 
measure  which  may  be  used  to  evaluate  the  component  against 
a  different  component  evaluated  using  the  same  set  of  de¬ 
sired  characteristics. 

The  absolute  measure  of  component  strengths  and  weak¬ 
nesses  may  be  identified  by  establishing  meaningful  "cutoff" 
values  within  the  range  of  possible  rating  values.  In  this 
case,  the  following  values  were  selected:  1)  a  component 
characteristic  was  considered  missing  if  the  actual  rating 
was  zero,  2)  a  component  characteristic  was  considered  to  be 
present  but  "weak"  if  the  actual  rating  was  less  than  50 
percent  of  the  maximum  possible  rating,  and  3)  a  component 
characteristic  was  considered  to  be  present  and  "strong"  if 
the  actual  rating  was  greater  than  80  percent  of  the  maximum 
possible  rating. 

Using  the  values  established  above  the  prototype  custo¬ 
dian  possesses  the  strengths  and  weaknesses  listed  below. 

1.  Absent  Characteristics: 

a.  Selectable  levels  of  user  assistance. 

b.  Ability  to  customize  command  names. 
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c.  Ability  to  execute  commands  input  from 
disk  files. 

d.  Ability  to  tailor  output  messages  to  suit 
the  user. 

e.  Storage  of  requests  by  the  user  to  add, 
delete,  or  modify  the  toolkit  in  the 
toolkit  temporary  storage  area. 

2.  Characteristics  present  but  "weak": 

a.  On-line  help  and  aid  to  the  user  at  each 
decision  point. 

b.  Input  data  format  analysis. 

c.  Treatment  of  all  user  input  data  as 
temporary  data. 

d.  Complete  control  of  all  data  after  it  has 
been  identified  as  input  data. 

e.  Complete  control  of  the  parameters  used  during 
component  execution. 

3.  Characteristics  present  and  "strong": 

a.  Capability  to  easily  select  toolkit 
components . 

b.  The  user  can  easily  identify  user- 
selectable  data  needed  for  component 
execution. 

c.  User  access  levels  are  verified  in  a 
manner  that  does  not  reveal  the 
verification  method. 

d.  A  history  is  maintained  for  all  toolkit 
sessions. 

e.  The  custodian  controls  access  to  all 
drawer  components. 

f.  The  user  cannot  modify  data  resident  in 
permanent  storage. 

g.  The  custodian  controls  the  sequence  of 
drawer  usage. 

h.  The  custodian  controls  the  sequence  of 
component  execution. 

The  second,  and  most  useful,  measure  that  emerged 
during  the  evaluation  was  the  relative  measure  of  the  compo¬ 
nent.  This  measure  is  described  in  the  evaluation  as  the 
drawer  quality  (DQ).  This  measure  identifies  the  level  of 
success  in  achieving  all  the  desired  drawer  components.  In 
this  case,  the  level  of  success  was  approximately  67  per¬ 
cent.  This  value,  when  compared  to  other  evaluations  done 


using  the  same  set  of  desired  characteristics,  can  be  used 
to  select  the  "best"  drawer  from  a  collection  of  similar 
drawers.  Selection  could  be  based  upon  the  drawer  with  the 
highest  drawer  quality. 

This  evaluation  technique  shows  promise.  The  technique 
is  simple  enough  to  be  used  by  technical  and  non-technical 
users.  Further  testing  of  the  method  is  required.  Perhaps 
a  useful  approach  would  be  to  permit  several  potential 
users,  designers,  and  maintainers  to  perform  the  evaluation. 
The  collection  of  evaluation  data  could  then  be  statistical¬ 
ly  averaged  and  a  generally  agreed-upon  set  of  ratings 
established  for  the  drawer. 

Summary 

A  prototype  toolkit  and  its  custodian  have  been  design¬ 
ed,  implemented,  and  evaluated  with  the  intention  of  illus¬ 
trating  and  evaluating  the  proposed  CAD  tool  integration 
methodology.  The  tasks  involved  in  the  prototype  task  have 
been  discussed  and  a  preliminary  evaluation  of  integration 
methodology  has  been  presented. 

Implementation  of  a  prototype  toolkit  and  its  custodian 
have  indicated  the  general  utility  of  the  proposed  methods. 
It  is  clear  that  the  task  of  integrating  a  collection  of  CAD 
tools  is  not  a  trivial  task.  Some  portions  of  the  task  will 
require  highly  skilled  people  (eg.  the  distribution  of 
existing  tools).  Other  portions  of  the  task  are  relatively 
easy  but  will  be  time-consuming  and  tedious  (eg.  evaluation 
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of  each  toolkit  drawer  and  its  components).  The  component 
evaluation  technique  and  its  associated  metrics  produced 
absolute  and  relative  measures  of  the  success  in  achieving  a 
desired  set  of  drawer  characteristics.  These  measures  can 
be  useful  when  considering  the  internal  strengths  and  weak¬ 
nesses  of  a  drawer  and  when  selecting  the  "best"  drawer  from 
a  collection  of  similar  drawers. 

The  following  chapter  concludes  this  document  and  pre¬ 
sents  this  author's  conclusions  and  recommendations  for 


future  work. 


VII.  Conclusions  and  Recommendations 


Synopsis 

It  has  been  proposed  and  exemplified  that  the  success 
of  future  VLSI  design  efforts  is  contingent  upon  the  evolu¬ 
tion  of  a  new  design  philosophy  and  upon  the  production  of 
"tall-thin"  VLSI  design  engineers.  The  lack  of  an  inte¬ 
grated,  compatible  set  of  VLSI  CAD  tools  has  been  identified 
as  a  serious  problem  which  prohibits  the  optimization  of  the 
academic  programs  necessary  to  produce  the  required  VLSI 
design  engineers. 

This  thesis  proposes  that  the  CAD  tool  problem  may  be 
solved  through  the  development  of  a  VLSI  CAD  "toolkit".  The 
characteristics  of  an  integrated,  technically  complete, 
academically-oriented  VLSI  CAD  toolkit  have  been  presented. 
A  systematic  method  to  integrate  CAD  tools  has  been  detailed 
and  supported  through  the  development  of  a  set  of  CAD  tool 
evaluation  metrics.  Finally,  a  prototype  VLSI  CAD  toolkit 
and  its  custodian  were  designed,  implemented,  and  evaluated. 

Conclusions 

It  is  this  author's  opinion  that  all  complex  entities 
have  evolved  from  simplistic  principles.  The  development  of 
a  complex,  intricate  structure  or  idea  clearly  must  begin 
with  the  recognition  and  clear  description  of  its  simple 
basis.  This  philosophy  prevailed  throughout  this  work. 

The  description  of  a  VLSI  CAD  toolkit  as  a  simple 
collection  of  drawers  established  a  most  useful  basis  for 


VII-1 


the  detailed  toolkit  characterization  that  followed.  Desir¬ 
able  toolkit  characteristics  and  properties  were  assembled 
from  the  published  comments  of  VLSI  design  experts,  conver¬ 
sations  with  AFIT  faculty  and  students,  and  from  this 
author's  limited  personal  experience  with  VLSI  CAD  tools. 
Admittedly,  the  toolkit  characterization  may  be  biased 
toward  the  parochial  interests  of  the  author  and  AFIT. 
Certainly,  the  characterization  is  incomplete  since  no 
direct  input  was  obtained  from  other  academic  institutions 
with  similar  VLSI  programs.  Although  biased  and  incom¬ 
plete,  the  toolkit  characterization  touches  the  major  needs 
of  VLSI  designers  as  seen  in  the  literature  and  should 
provide  a  viable  foundation  for  future  work. 

The  methodology  proposed  for  the  systematic  integration 
of  CAD  tools  also  has  its  basis  in  simplicity.  No  new  or 
startling  ideas  are  seen  in  the  proposed  integration 
methods.  Rather,  the  reader  will  find  a  logical  progression 
of  tasks  that  form  the  simple  basis  of  any  product  evalua¬ 
tion.  The  complex  metrics  found  so  often  in  software  eval¬ 
uation  projects  have  purposely  been  avoided.  Mathematically 
naive  metrics  were  presented  which  were  easy  to  assign,  to 
calculate,  and  to  revise.  The  proposed  metrics  appear  to 
have  substantial  utility  as  indicators  of  the  "level  of 
presence"  of  desired  toolkit  characteristics.  The  evalua¬ 
tion  of  the  prototype  toolkit  custodian  revealed  the 
strengths  and  weaknesses  of  the  program  that  were  known  to 
this  author  a  priori.  Further  application  of  the  metrics  by 
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disinterested  parties  must  be  accomplished  if  the  true 
utility  of  the  metrics  is  to  be  determined. 

The  suggested  VLSI  CAD  toolkit  structure  evolved  in 
part  from  this  author's  exposure  to  the  UNIX  computer  oper¬ 
ating  system  developed  at  the  Bell  Laboratories.  The  tool¬ 
kit  structure  is  not  dependent  upon  the  presence  of  that 
operating  system.  The  toolkit  configuration  is  dependent 
upon  an  computer  which  supports  hierarchical  directory 
structures.  It  is  not  believed  that  the  toolkit  dependence 
upon  hierarchical  directory  structures  is  a  limitation  since 
the  trend  in  modern  computer  operating  systems  seems  to 
favor  those  structures. 

The  integration  of  a  collection  of  VLSI  CAD  tools  into 
a  complete  toolkit  should  be  a  simple  task  but  it  will  not 
be  a  trivial  one.  The  quantity  of  work  and  the  spectrum  of 
expertise  required  will  be  substantial.  The  successful 
implementation  of  a  VLSI  CAD  toolkit,  using  the  methodology 
suggested  in  this  work,  will  enable  academic  institutions  to 
optimize  their  VLSI  curricula  and  to  produce  the  types  of 
VLSI  design  engineers  the  future  demands. 

Recommendations 

The  simple  basis  of  an  integrated  VLSI  CAD  toolkit  has 
been  provided.  The  successful  evolution  of  such  a  toolkit 
will  require  substantial  future  efforts.  The  tasks  de¬ 
scribed  below  should  be  included  in  those  efforts. 

1.  The  productivity  of  some  VLSI  courses  (and  the 
major  thrust  of  this  thesis)  should  be  evaluated 
through  the  use  of  the  prototype  toolkit  and  its 


associated  custodian. 


2.  The  toolkit  characterization  must  be  com¬ 
pleted.  First,  all  locally  interested  parties 
should  be  provided  the  opportunity  to  contribute 
to  the  characterization.  Second,  input  to  the 
toolkit  characterization  should  be  obtained  from 
all  other  academic  institutions  with  VLSI  curricu¬ 
la. 

3.  The  toolkit  metrics  proposed  herein  should  be 
carefully  examined.  It  is  recommended  that  the 
evaluation  of  the  prototype  custodian  be  accom¬ 
plished  by  a  group  of  actual  and  potential  users 
of  VLSI  CAD  tools.  The  group  should  not  be  lim¬ 
ited  to  those  intimately  familiar  with  VLSI  design 
or  CAD  tools.  The  intention  is  to  make  VSLI 
design  available  to  many  disciplines. 


4.  The  prototype  custodian  should  be  rewritten  in 
a  language  that  is  generally  transportable  (eg. 
"C")  and  provided  to  interested  parties  for  their 
evaluation. 

5.  The  distribution  of  AFIT  CAD  tools  should  be 
independently  accomplished  by  a  group  of  people 
who  are  intimately  familiar  with  the  CAD  tools. 
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CUS  1  Ass^qn  User  Access  Level 


Acstract:  The  first  activity  of  this  process  is  the  creation  of  a  temporary  log  in  which 
will  be  recorded  all  significant  activity  during  this  toolkit  session.  This  process  then 
examines  the  access  level  of  the  user  and,  if  the  user  is  an  authorized  user,  performs  the 


Figure  A-4  SADT  for  Custodian  Node  CUS2 


Abstract:  This  process  forms  the  core  of  the  custodian.  At  this  level  the  user  requests 
are  obtained  and  analyzed.  If  the  analysis  detects  an  error  in  the  syntatical  or  logical 
structure  of  a  request,  then  action  is  taken  to  resolve  the  error.  Verification  of 
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CUS34  Analyze  Response  -  The  process  performs  the  activities  necessary  to  examine  and 
analyze  the  latest  toolkit  response  to  a  user  request.  If  the  response  was  terminated  due 
to  an  error,  detailed  information  concerning  the  error  is  provided  to  the  user.  Help  is 
provided  to  the  user  to  aid  in  the  interpretation  and  correction  of  the  error.  An 
analysis  code  is  generated  which  reflects  the  overall  successfulness  of  the  response. 


SADT  for  Custodian  Node  CUS3 


Abstract:  This  process  "gracefully"  closes  the  toolkit.  Storage  space  which  was  tempor¬ 
arily  reserved  for  this  session  is  purged.  The  toolkit  management  data  is  updated  and 
stored.  The  temporary  log  opened  to  record  this  session's  activity  is  appended  to  the 
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TYPE:  ACTIVITY 
DATE:  10  October  1984 
NUMBER:  CUS-0 

NAME:  Provide  Toolkit  Custodian 

INPUTS:  Sys  Progs, Msgs,  Data 

User  Msgs  &  Data 

OUTPUTS:  Msgs  &  Data  to  User  Terminal 

Msgs  &  Data  to  Disk  Piles 
Msgs  &  Data  to  Computer  Peripherals 
CONTROLS :  None . 

MECHANISMS:  AFIT  VAX  11/780  with  Unix  Os. 

DESCRIPTION:  Environment  Node  for  the  VLSI  CAD  Toolkit 
Custodian.  This  custodian  provides  the  interface  between 
the  toolkit  and  the  outside  world.  The  custodian  also 
provides  complete  control  of  the  toolkit  execution  and 
dataflow. 

RELATED  REQUIREMENT  NUMBER:  N/A 
ALIASES:  None. 


TYPE:  ACTIVITY 

DATE:  10  October  1984 

NUMBER:  CUS1 

NAME:  Assign  User  Access  Level 
INPUTS:  None. 

OUTPUTS:  User  Access  level 

CONTROLS:  User  Access  Lists 
User  Id 
MECHANISMS:  None. 

DESCRIPTION:  This  process  performs  a  single  function; 

assignment  of  an  access  level  code  to  the  user  requesting 
access  to  the  VLSI  CAD  toolkit.  The  access  level  will  be 
determined  by  searching  pre-established  lists  of  authorized 
users  for  the  presence  of  the  requester's  user  id.  In  the 
event  the  requester's  user  id  appears  in  more  than  one  list, 
the  access  code  will  reflect  an  access  level  which 
encompasses  the  access  permitted  by  all  matching  lists. 
RELATED  REQUIREMENT  NUMBER:  N/A 
ALIASES:  None. 
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TYPE:  ACTIVITY 

DATE:  10  October  1984 

NUMBER:  CUS2 

NAME:  Open  Toolkit 

INPUTS:  Toolkit  Mgt  Data 

OUTPUTS:  Templog  Entry 

Toolkit  Mgt  Data 
Status  Msgs 

CONTROLS:  User  Access  Level 

MECHANISMS:  None. 

DESCRIPTION:  The  first  activity  of  this  process  is  the 

creation  of  a  temporary  log  in  which  will  be  recorded  all 
significant  activity  during  this  toolkit  session.  This 
process  then  examines  the  access  level  of  the  user  and,  if 
the  user  is  an  authorized  user,  performs  the  activities 
necessary  to  ensure  that  the  system  environment,  the  user 
interface,  and  the  toolkit  components  are  available  and 
configured  to  ensure  successful  execution  of  all  the  toolkit 
components  accessible  by  the  user.  If  the  user  is  not 
authorized  access,  the  user  is  counseled  concerning  the 
steps  necessary  to  gain  access  and  an  entry  is  made  in  the 
toolkit  security  log  concerning  this  execution  attempt. 
RELATED  REQUIREMENT  NUMBER:  N/A 
ALIASES:  None. 


TYPE:  ACTIVITY 

DATE:  10  October  1984 

NUMBER:  CUS21 

NAME:  Open  for  Authorized  User 
INPUTS:  Toolkit  Mgt  Data 

OUTPUTS:  Templog  Entry 

Toolkit  Mgt  Data 
Status  Msgs 

CONTROLS:  User  Access  Level 

MECHANISMS:  None. 

DESCRIPTION:  This  process  performs  the  necessary  activities 
to  open  the  toolkit  for  use  by  an  authorized  toolkit  user. 
Those  components  of  the  toolkit  management  data  which  are 
affected  by  an  authorized  toolkit  access  are  updated  and 
appropriate  entries  are  made  in  the  temporary  log.  Status 
messages  are  provided  the  user  to  ensure  the  required 
feedback  is  provided. 

RELATED  REQUIREMENT  NUMBER:  N/A 
ALIASES:  None. 


TYPE:  ACTIVITY 
DATE:  10  October  1984 

NUMBER:  CUS22 

NAME:  Record  Unauthorized  User  Access  Attempt 

INPUTS:  None. 

OUTPUTS:  Status  Msgs 

Security  Log  Entry 
CONTROLS:  User  Access  Level 
MECH AN ISMS:  None . 

DESCRIPTION:  This  process  records  an  attempt  to  open  the 

toolkit  by  an  unauthorized  user.  The  user  is  provided 
instructions  concerning  the  steps  necessary  to  gain  access 
authorization . 

RELATED  REQUIREMENT  NUMBER:  N/A 
ALIASES:  None. 
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TYPE:  ACTIVITY 

DATE:  10  October  1984 

NUMBER:  CUS3 

NAME:  Provide  Toolkit 

INPUTS:  Toolkit  Mgt  Data 

Sys  Progs,  Msgs,  Data 
User  Msgs  &  Data 
OUTPUTS:  Templog  Entry 

Security  Log  Entry 
Data  &  Msgs 
Toolkit  Mgt  Data 
CONTROLS:  User  Access  Level 

MECHANISMS:  None. 

DESCRIPTION:  This  process  forms  the  core  of  the  custodian. 

At  this  level  the  user  requests  are  obtained  and  analyzed. 
If  the  analysis  detects  an  error  in  the  syntatical  or 
logical  structure  of  a  request,  then  action  is  taken  to 
resolve  the  error.  Verification  of  resource  availability 
occurs  during  the  analysis  of  the  user  requests.  If  the 
user  requests  successfully  pass  the  analysis  step,  then  the 
a  response  to  the  requests  is  selected  and  the  appropriate 
toolkit  components  are  executed.  The  toolkit  response  to 
the  user  requests  in  analyzed  following  completion  of  the 
response.  Throughout  this  process  appropriate  statistics, 
messages,  and  data  are  generated  and  stored. 

RELATED  REQUIREMENT  NUMBER:  N/A 
ALIASES:  None. 
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TYPE:  ACTIVITY 

DATE:  10  October  1984 

NUMBER:  CUS31 

NAME:  Obtain  User  Input 

INPUTS:  User  Msgs  &  Data 

OUTPUTS:  In_Log_Entry 

In_Secur_Entry 
Prompts  &  Msgs 
CONTROLS:  Analysis  Code 

User  Access  Level 
MECHANISMS:  None. 

DESCRIPTION:  This  process  performs  the  activities  necessary 
to  ascertain  the  skill  level  of  the  user,  present  selection 
options  to  the  user,  and  actually  obtain  the  user's  input. 
The  selection  options  provided  to  the  user  are  based  upon  an 
analysis  of  the  last  toolkit  response  to  a  user  request  as 
well  as  the  current  status  of  the  toolkit's  operating 
environment.  Appropriate  log  entries  are  stored.  Attempts 
to  violate  the  security  of  the  toolkit  are  detected  and 
recorded.  Help  is  provided  as  necessary. 

RELATED  REQUIREMENT  NUMBER:  N/A 
ALIASES:  None. 


TYPE:  ACTIVITY 
DATE:  10  October  1984 
NUMBER:  CUS32 

NAME:  Analyze  User  Input 
INPUTS:  Toolkit  Mgt  Data 

Sys  Progs,  Msgs,  Data 
User  Msgs  &  Data 
User  Input 

OUTPUTS:  In_Anal_Entry 

In_Anal_Sec_Entry 
In_Anal_Stats 
Action  Code 

CONTROLS:  User  Access  Level 

MECHANISMS:  None. 

DESCRIPTION:  This  process  parses  the  user  input  and 

analyzes  the  input  for  syntatical  and  logical  errors. 
Attempts  to  violate  toolkit  security  are  detected  and 
recorded.  An  action  code  is  generated  which  corresponds  to 
the  user's  component  selection  and  statistics  are  generated 
concerning  the  user  selection  and  the  parameters  selected  by 
the  user  for  use  during  the  execution  of  the  selected 
component.  Help  is  provided  as  necessary. 

RELATED  REQUIREMENT  NUMBER:  N/A 
ALIASES:  None. 


TYPE:  ACTIVITY 

DATE:  10  October  1984 

NUMBER:  CUS33 

NAME:  Respond  To  User  Input 

INPUTS:  Toolkit  Mgt  Data 

Sys  Progs,  Msgs,  Data 
User  Msgs  &  Data 
Parsed  Input 

OUTPUTS:  Output  Data  &  Msgs 
Response  Code 
Response  Stats 
CONTROLS:  Action  Code 
MECHANISMS:  None. 

DESCRIPTION:  This  process  executes  the  toolkit  components 

necessary  to  effect  a  complete  response  to  the  user  input. 
This  process  manages  and  controls  the  execution  sequence  and 
data  flow  until  the  response  is  completed.  Continuous 
feedback  is  provided  the  user  during  component  execution.  A 
response  code  is  generated  which  reflects  whether  or  not  the 
response  was  successfully  completed.  If  an  error  is 
detected  during  a  response,  an  attempt  is  made  to  recover 
from  the  error.  Help  is  provided  as  necessary. 

RELATED  REQUIREMENT  NUMBER:  N/A 
ALIASES:  None. 


TYPE:  ACTIVITY 
DATE:  10  October  1984 

NUMBER:  CUS34 
NAME:  Analyze  Response 
INPUTS:  Toolkit  Mgt  Data 

Sys  Progs,  Msgs,  Data 
User  Msgs  &  Data 
Response  Stats 
OUTPUTS:  Analysis  Code 
Analysis  Msgs 
Close  Sequense 
CONTROLS:  Response  Code 
MECHANISMS:  None. 

DESCRIPTION:  The  process  perforins  the  activities  necessary 

to  examine  and  analyze  the  latest  toolkit  response  to  a  user 
request.  If  the  response  was  terminated  due  to  an  error, 
detailed  information  concerning  the  error  is  provided  to  the 
user.  Help  is  provided  to  the  user  to  aid  in  the 
interpretation  and  correction  of  the  error.  An  analysis 
code  is  generated  which  reflects  the  overall  successfulness 
of  the  response. 

RELATED  REQUIREMENT  NUMBER:  N/A 
ALIASES:  None. 


TYPE:  ACTIVITY 
DATE:  10  October  1984 

NUMBER:  CUS4 

NAME:  Close  Toolkit 
INPUTS:  Templog 

Permlog 

Toolkit  Mgt  Data 
OUTPUTS:  Msgs 

Toolkit  Mgt  Data 
Permlog 

CONTROLS:  Close  Sequence 
MECHANISMS:  None. 

DESCRIPTION:  This  process  "gracefully"  closes  the  toolkit. 
Storage  space  which  was  temporarily  reserved  for  this 
session  is  purged.  The  toolkit  management  data  is  updated 
and  stored.  The  temporary  log  opened  to  record  this 
session's  activity  is  appended  to  the  permanent  toolkit  log. 
A  closing  message  is  generated  and  the  custodian  ceases 
execution. 

RELATED  REQUIREMENT  NUMBER:  N/A 
ALIASES:  None. 
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TYPE:  ACTIVITY 
DATE:  10  October  1984 
NUMBER:  CUS41 

NAME:  Purge  Temporary  Storage 

INPUTS:  None. 

OUTPUTS:  Storage  Request 

CONTROLS:  Close  Sequence 
MECHANISMS:  None. 

DESCRIPTION:  This  process  purges  the  toolkit  temporary 

storage  are  of  all  files  generated  during  this  session  which 
are  no  longer  required.  Some  files  may  remain  if  the  user 
has  requested  that  they  be  added  to  the  permanent  storage 
area.  If  files  remain  for  addition  to  the  permanent  storage 
area,  then  an  appropriate  storage  request  is  generated. 
This  message  will  be  presented  to  those  responsible  for  the 
toolkit  configuration  and  maintenance. 

RELATED  REQUIREMENT  NUMBER:  N/A 
ALIASES:  None. 


TYPE:  ACTIVITY 
DATE:  10  October  1984 

NUMBER:  CUS42 

NAME:  Update  Toolkit  Management  Data 

INPUTS:  Toolkit  Mgt  Data 

OUTPUTS:  Usage  Stats 

Toolkit  Mgt  Data 
CONTROLS:  Storage  Request 

Close  Sequence 
MECHANISMS:  None. 

DESCRIPTION:  This  process  performs  the  activities  necessary 
to  bring  all  of  the  toolkit  management  data  up-to-date  with 
respect  to  the  activities  that  occurred  during  this  user 
session.  The  toolkit  management  data  includes  requests  to 
move  temporary  storage  files  to  the  permanent  storage  area. 
Session  statistics  are  provided  to  the  user. 

RELATED  REQUIREMENT  NUMBER:  N/A 
ALIASES:  None. 
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TYPE:  ACTIVITY 

DATE:  10  October  1984 

NUMBER:  CUS43 

NAME:  Append  Temporary  Log  to  Permanent  Log 
INPUTS:  Templog 
Permlog 

OUTPUTS:  Permlog 

CONTROLS:  Close  Sequence 
MECHANISMS:  None. 

DESCRIPTION:  This  process  appends  the  temporary  log 

generated  and  maintained  during  this  session  to  the  current 
permanent  toolkit  log.  The  temporary  log  is  then  removed 
and  discarded. 

RELATED  REQUIREMENT  NUMBER:  N/A 
ALIASES:  None. 


TYPE:  ACTIVITY 
DATE:  10  October  1984 
NUMBER:  CUS44 

NAME:  Send  Closing  Messages 
INPUTS:  None. 

OUTPUTS:  Close  Msgs 
CONTROLS:  Close  Sequence 
MECHANISMS:  None. 

DESCRIPTION:  This  process  generates  appropriate  messages  to 
let  the  user  know  that  the  session  has  "gracefully"  ended. 
Messages  are  also  sent  to  the  toolkit  maintainers  concerning 
matters  which  have  arisen  during  this  session  which  require 
attention  (eg.  a  request  to  make  an  addition  to  the  toolkit 
permanent  storage  or  user  comments). 

RELATED  REQUIREMENT  NUMBER:  N/A 
ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Sys  Progs,  Msgs,  Data 

DESCRIPTION:  Executable  programs,  data,  and  messages  which 

are  integral  parts  of  the  support  computer  operating  system. 
SOURCES:  Support  Computer  Operating  System 

DESTINATIONS:  CUSO  CUS1  CUS3 

COMPOSITION:  Executable  Programs,  Data  generated  by  the 

executable  programs,  data  stored  in  system-level  disk  files 
or  system-level  operating  system  variables,  and  messages 
generated  by  the  executable  programs  or  by  the  operating 
system. 

DATA  CHARACTERISTICS:  Executable  Programs  are  binary.  All 
other  data  is  composed  of  binary  representations  of 
characters  (ASCII)  or  numbers. 

ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Msgs  &  Data  To  User  Terminal 

DESCRIPTION:  Messages  and  data  sent  directly  to  the  user's 

terminal . 

SOURCES:  CUSO 

DESTINATIONS:  User  Terminal 

COMPOSITION:  Data  generated  by  toolkit  components,  stored 

in  toolkit-accessible  disk  files  or  in  toolkit  or  system- 
level  variables,  and  messages  generated  by  toolkit 
components . 

DATA  CHARACTERISTICS:  All  data  and  messages  are  composed 

of  binary  representations  of  characters  (ASCII)  or  numbers. 
ALIASES:  None. 


TYPE:  DATA  ELEMENT 

DATE:  10  October  1984 

NAME:  Msgs  &  Data  to  Disk  Files 

DESCRIPTION:  Messages  and  data  sent  to  disk  files 
SOURCES:  CUSO 

DESTINATIONS:  Disk  Files 

COMPOSITION:  Data  generated  by  toolkit  components,  stored 

in  toolkit-accessible  disk  files  or  in  toolkit  or  system- 
level  variables,  and  messages  generated  by  toolkit 
components . 

DATA  CHARACTERISTICS:  All  data  and  messages  are  composed 
of  binary  representations  of  characters  (ASCII)  or  numbers. 
ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Msgs  &  Data  to  Computer  Peripherals 

DESCRIPTION:  Messages  and  data  sent  to  the  peripherals 

attached  to  the  support  computer  system  or  to  the  user 
terminal . 

SOURCES:  CUSO 

DESTINATIONS:  Peripherals  attached  to  the  support  computer 

system  or  to  the  user  terminal. 

COMPOSITION:  Data  generated  by  toolkit  components,  stored 

in  toolkit-accessible  disk  files  or  in  toolkit  or  system- 
level  variables,  and  messages  generated  by  toolkit 
components . 

DATA  CHARACTERISTICS:  All  data  and  messages  are  composed 

of  binary  representations  of  characters  (ASCII)  or  numbers. 
ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Msgs  Data  to  Computer  Peripherals 

DESCRIPTION:  Messages  and  data  sent  to  the  peripherals 

attached  to  the  support  computer  system  or  to  the  user 
terminal . 

SOURCES:  CUSO 

DESTINATIONS:  Peripherals  attached  to  the  support  computer 

system  or  to  the  user  terminal. 

COMPOSITION:  Data  generated  by  toolkit  components,  stored 

in  toolkit-accessible  disk  files  or  in  toolkit  or  system- 
level  variables,  and  messages  generated  by  toolkit 
components . 

DATA  CHARACTERISTICS:  All  data  and  messages  are  composed 

of  binary  representations  of  characters  (ASCII)  or  numbers. 
ALIASES:  None. 
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TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  User  Access  Lists 

DESCRIPTION:  Lists  of  unique  user  identifiers  (user  ids) 

which  are  segregated  according  to  the  various  levels  of 
toolkit  access  permitted  the  users. 

SOURCES:  Resident  in  the  support  computer  disk  storage 

area. 

DESTINATIONS:  CUS1 

COMPOSITION:  Unique  user  identifiers 

PART  OF:  Sys  Progs,  Msgs,  Data 

DATA  CHARACTERISTICS:  ASCII  characters 

VALUES:  Range  of  values  permitted  by  the  host  computer 

operating  system  for  the  unique  identification  of  users. 
ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  User  Id 

DESCRIPTION:  The  unique  identifier  assigned  by  the 

operating  system  for  the  current  user.  Usually  stored  in  an 
operating  system  variable. 

SOURCES:  Support  Computer  Operating  System. 

DESTINATIONS:  CUS1 

COMPOSITION:  Unique  user  identifier 

DATA  CHARACTERISTICS:  ASCII  characters 

VALUES:  Range  of  values  permitted  by  the  host  computer 

operating  system  for  the  unique  identification  of  users. 
ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  User  Access  Level 

DESCRIPTION:  Descriptor  which  indicates  the  level  of  access 
that  is  to  be  given  the  current  toolkit  user.  This  level  of 
access  is  used  to  determine:  1)  which  toolkit  components 
may  be  executed  by  the  user,  2)  the  types  and  quantities  of 
toolkit  data  that  will  be  accessible  to  the  user,  and  3)  the 
priority  of  this  user's  requests  relative  to  other  toolkit 
processing  tasks  (including  other  user  requests) . 

SOURCES:  CUS1 

DESTINATIONS:  CUS2  CUS21  CUS22  CUS3  CUS31  CUS32 
COMPOSITION:  A  number  is  used  to  represent  the  level  of 

access . 

DATA  CHARACTERISTICS:  A  single  integer. 

VALUES:  0  :  No  access  permitted  -  TBD  based  upon  highest 

level  of  access. 

ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Templog  Entry 

DESCRIPTION:  Message  generated  by  the  toolkit  custodian 

which  indicates  the  occurrence  of  a  toolkit  "event".  This 
entry  is  stored  in  the  temporary  log  assigned  to  the  current 
user  session. 

SOURCES:  CUS2  CUS21  CUS3 
DESTINATIONS:  Toolkit  temporary  log 

COMPOSITION:  Message  describing  the  occurrence  of  a  toolkit 

"event" . 

PART  OF:  Msgs  &  Data  to  Disk  Files 

DATA  CHARACTERISTICS:  All  messages  are  composed  of  binary 
representations  of  characters  (ASCII)  or  numbers. 

ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Toolkit  Mgt  Data 

DESCRIPTION:  Data  necessary  to  manage  toolkit  component 

execution,  the  toolkit  configuration,  and  all  toolkit 
resources . 

SOURCES:  Resides  in  support  computer  system  disk  files  and 

variables.  Is  updated/modified  by  CUS2  CUS3  CUS4 
DESTINATIONS:  CUS2  CUS3  CUS4 

COMPOSITION:  Toolkit  access  data,  user  request  data, 

toolkit  resource  data,  operating  system  resource  data, 
toolkit  component  performance  data,  and  toolkit  maintenance 
data  and  attention  flags. 

PART  OF:  Msgs  &  Data  to  Disk  Files 

DATA  CHARACTERISTICS:  All  data  and  attention  flags  are 
composed  of  binary  representations  of  characters  (ASCII)  or 
numbers . 

ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Security  Log  Entry 

DESCRIPTION:  Message  generated  by  the  toolkit  custodian 

which  indicates  the  occurrence  of  a  toolkit  security 
"event".  This  entry  is  stored  in  the  toolkit  security  log. 
SOURCES:  CUS2  CUS3 
DESTINATIONS:  Toolkit  security  log 

COMPOSITION:  Message  describing  the  occurrence  of  a  toolkit 

security  "event". 

PART  OF:  Msgs  &  Data  to  Disk  Files 

DATA  CHARACTERISTICS:  All  messages  are  composed  of  binary 
representations  of  characters  (ASCII)  or  numbers. 

ALIASES:  None. 
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TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Status  Msgs 

DESCRIPTION:  Messages  generated  that  provide  the  user  with 

feedback  concerning  the  tasks  being  processed  by  the  toolkit 
custodian  when  the  toolkit  is  being  opened  for  use. 

SOURCES:  CUS2  CUS21  CUS22 
DESTINATIONS:  User  Terminal 

COMPOSITION:  Message  describing  the  current  task  being 

processed  by  the  toolkit  custodian. 

PART  OF:  Msgs  &  Data  to  User  Terminal 

DATA  CHARACTERISTICS:  All  messages  are  composed  of  binary 
representations  of  characters  (ASCII)  or  numbers. 

ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Data  s.  Msgs 

DESCRIPTION:  Data  and  messages  generated  by  the  toolkit  when 
performing  the  tasks  necessary  to  process  a  user's  request. 
SOURCES:  CUS3 

DESTINATIONS:  User  terminal 

Disk  files 

Computer  peripherals  attached  to  the  support 
computer  or  to  the  user  terminal. 

COMPOSITION:  Data  generated  by  toolkit  components,  stored 

in  toolkit-accessible  disk  files  or  in  toolkit  or  system- 
level  variables,  and  messages  generated  by  toolkit 
components . 

PART  OF:  Msgs  &  Data  to  User  Terminal 
Msgs  &  Data  to  Disk  Files 
Msgs  &  Data  to  Computer  Peripherals 
DATA  CHARACTERISTICS:  All  data  and  messages  are  composed 
of  binary  representations  of  characters  (ASCII)  or  numbers. 
ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Close  Sequence 

DESCRIPTION:  An  ordered  sequence  of  codes  which  identify 
the  tasks  which  are  to  be  accomplished  by  the  toolkit 
custodian  when  closing  the  toolkit. 

SOURCES:  CUS3  CUS34 

DESTINATIONS:  CUS4  CUS41  CUS42  CUS43  CUS44 
COMPOSITION:  An  ordered  sequence  of  task  codes. 

DATA  CHARACTERISTICS:  Binary  representations  of  characters 

(ASCII)  or  numbers. 

VALUES:  TBD  -  Task  codes  to  be  assigned  during  toolkit 

construction. 

ALIASES:  None. 
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TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Templog 

DESCRIPTION:  A  diskfile  containing  entries  describing 
toolkit  "events".  A  toolkit  event  is  any  user  entry, 
toolkit  output  message,  or  toolkit  activity  which  would  play 
an  essential  part  in  any  reconstruction  of  the  user  session. 
The  entries  are  maintained  in  the  order-of-arrival  and  may 
be  date/time  stamped.  Used  to  maintain  the  "history"  of  a 
particular  user  toolkit  session. 

SOURCES:  Resides  in  the  temporary  storage  area  of  the 

toolkit.  One  log  is  created  for  each  user  session. 
DESTINATIONS:  CUS4  CUS43 

COMPOSITION:  In_Log_Entry 

Templog  Entry 
In_Anal_Entry 
Analysis  Msgs 

PART  OF:  Msgs  &  Data  to  Disk  Files 

DATA  CHARACTERISTICS:  All  messages  are  composed  of  binary 
representations  of  characters  (ASCII)  or  numbers. 

ALIASES:  Temporary  Log 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Perm log 

DESCRIPTION:  A  diskfile  containing  entries  describing 

toolkit  events.  The  entries  are  maintained  in  the  order-of- 
arrival  and  may  be  date/time  stamped.  Used  to  maintain  the 
"history"  of  the  toolkit  for  a  particular  period  of 
interest . 

SOURCES:  Resides  in  the  permanent  storage  area  of  the 

toolkit.  One  log  is  maintained  for  each  toolkit  historical 


quarter  or  by  year). 


"temporary  logs"  (Templog) : 


segment  (eg.  by  month  or  by  quarter  or  by  year). 
DESTINATIONS:  CUS4  CUS43 

COMPOSITION:  Concattenated  "temporary  logs"  (Templog) : 

In_Log_Entry 
Templog  Entry 
In_Anal_Entry 
Analysis  Msgs 

PART  OF:  Msgs  &  Data  to  Disk  Files 

DATA  CHARACTERISTICS:  All  messages  are  composed  of  binary 
representations  of  characters  (ASCII)  or  numbers. 

ALIASES:  Permanent  Log 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Msgs 

DESCRIPTION:  Messages  generated  during  the  closing  of  the 

toolkit  that  provide  the  user  with  feedback  concerning  the 
status  of  the  toolkit  and  their  toolkit  session. 

SOURCES:  CUS4 

DESTINATIONS:  User  Terminal 

COMPOSITION:  Message  describing  the  status  of  the  toolkit 

and  the  current  toolkit  session. 

PART  OF:  Msgs  &  Data  to  User  Terminal 

DATA  CHARACTERISTICS:  All  messages  are  composed  of  binary 
representations  of  characters  (ASCII)  or  numbers. 

ALIASES:  None. 
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TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  I n_Log_E n  t r  y 

DESCRIPTION:  Message  generated  by  the  toolkit  custodian 

which  indicates  the  occurrence  of  a  toolkit  "event"  during 
acquisition  of  the  user  input  and  messages.  This  entry  is 
stored  in  the  temporary  log  assigned  to  the  current  user 
session. 

SOURCES:  CUS31 

DESTINATIONS:  Toolkit  temporary  log 

COMPOSITION:  Message  describing  the  occurrence  of  a  toolkit 

"event"  during  acquisition  of  user  input  data  and  messages. 
PART  OF:  Templog  Entry 

DATA  CHARACTERISTICS:  All  messages  are  composed  of  binary 
representations  of  characters  (ASCII)  or  numbers. 

ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  In_Secur_Entry 

DESCRIPTION:  Message  generated  by  the  toolkit  custodian 

which  indicates  the  occurrence  of  a  toolkit  security  "event" 
during  acquisition  of  the  user  input  and  messages.  This 
entry  is  stored  in  the  temporary  log  assigned  to  the  current 
user  session. 

SOURCES:  CUS31 

DESTINATIONS:  Toolkit  security  log 

COMPOSITION:  Message  describing  the  occurrence  of  a  toolkit 

security  "event"  during  acquisition  of  user  input  data  and  messages 
PART  OF:  Security  Log  Entry 

DATA  CHARACTERISTICS:  All  messages  are  composed  of  binary 
representations  of  characters  (ASCII)  or  numbers. 

ALIASES:  None. 


TYPE;  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Prompts  &  Msgs 

DESCRIPTION:  Prompts  and  messages  generated  during  the 

acquisition  of  user  input  messages  and  data  that  provide  the 
user  with:  1)  selection  options,  2)  feedback  concerning 
input  selections,  3)  Input  assistance,  and  4)  error 
responses . 

SOURCES:  CUSH 
DESTINATIONS:  User  Terminal 

COMPOSITION:  Messages  and  data  which  originate  from:  1) 

the  custodian,  2)  toolkit  variables,  3)  toolkit  help 
files,  and  4)  the  user  (echoed  from  user  input) . 

PART  OF:  Data  &  Msgs 

DATA  CHARACTERISTICS:  All  messages  are  composed  of  binary 
representations  of  characters  (ASCII)  or  numbers. 

ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Analysis  Codes 

DESCRIPTION:  Codes  which  identifies  the  level  of  success 
achieved  by  the  toolkit  during  a  response  to  a  user  request. 
As  a  minimum,  the  codes  must  identify  whether  or  not  the 
response  was  successful  or  failed.  Ideally,  the  codes  will 
indicate  the  portions  of  the  user  request  that  were 
successfully  completed  and  those  which  were  not  completed. 
If  portions  of  the  user  request  were  not  successfully 
completed,  then  the  codes  should  identify  the  reasons  for 
failure. 

SOURCES:  CUS34 
DESTINATIONS:  CUS31 

COMPOSITION:  Codes  identifying  the  success  or  failure  of 
each  toolkit  response  to  a  user  request. 

DATA  CHARACTERISTICS:  Binary  representations  of  characters 
(ASCII)  or  numbers. 

VALUES:  TBD  -  Analysis  codes  to  be  assigned  during  toolkit 

construction. 

ALIASES:  None. 
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TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  User  Input 

DESCRIPTION:  The  exact  input  acquired  from  the  user 

terminal . 

SOURCES:  CUS31 
DESTINATIONS:  CUS32 

COMPOSITION:  The  exact  input  acquired  from  the  user 

terminal . 

DATA  CHARACTERISTICS:  Binary  representations  of  characters 
(ASCII)  or  numbers. 

ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  In_Anal_Entry 

DESCRIPTION:  Message  generated  by  the  toolkit  custodian 

which  indicates  the  occurrence  of  a  toolkit  "event"  during 
analysis  of  the  user  input  and  messages.  This  entry  is 
stored  in  the  temporary  log  assigned  to  the  current  user 
session. 

SOURCES:  CUS32 

DESTINATIONS:  Toolkit  temporary  log 

COMPOSITION:  Message  describing  the  occurrence  of  a  toolkit 

"event"  during  analysis  of  user  input  data  and  messages. 

PART  OF:  Templog  Entry 

DATA  CHARACTERISTICS:  All  messages  are  composed  of  binary 
representations  of  characters  (ASCII)  or  numbers. 

ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  In_Anal_Sec_Entry 

DESCRIPTION:  Message  generated  by  the  toolkit  custodian 

which  indicates  the  occurrence  of  a  toolkit  security  "event" 
during  analysis  of  the  user  input  and  messages.  This  entry 
is  stored  in  the  temporary  log  assigned  to  the  current  user 
session. 

SOURCES:  CUS33 

DESTINATIONS:  Toolkit  security  log 

COMPOSITION:  Message  describing  the  occurrence  of  a  toolkit 

security  "event"  during  analysis  of  user  input  data  and 
messages . 

PART  OF:  Security  Log  Entry 

DATA  CHARACTERISTICS:  All  messages  are  composed  of  binary 
representations  of  characters  (ASCII)  or  numbers. 

ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  In_Anal_Stats 

DESCRIPTION:  These  are  statistics  developed  during  the 

analysis  of  a  particular  user  input. 

SOURCES:  CUS32 

COMPOSITION:  Statistics  concerning:  1)  individual  user 

component  selections,  2)  errors  detected  in  the  user 
input,  3)  status  of  support  computer  resources  at  the  time 
of  the  user  input  request,  and  4)  status  of  the  toolkit 
resources  at  the  time  of  the  user  input  request. 

PART  OF:  Toolkit  Mgt  Data 

DATA  CHARACTERISTICS:  All  statistics  are  composed  of 

binary  representations  of  characters  (ASCII)  or  numbers. 
Ideally,  the  statistics  will  be  represented  as  a  collection 
of  unique  names  with  appropriate  codes  or  frequencies 
attached  to  each  name  as  the  result  of  this  analysis. 


ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Action  Codes 

DESCRIPTION:  An  ordered  sequence  of  codes  which  identify 
the  responses  which  are  to  be  accomplished  by  the  toolkit 
custodian  when  responding  to  a  user  request. 

SOURCES:  CUS32 
DESTINATIONS:  CUS33 

COMPOSITION:  An  ordered  sequence  of  response  codes. 

DATA  CHARACTERISTICS:  Binary  representations  of  characters 
(ASCII)  or  numbers. 

VALUES:  TBD  -  Response  codes  to  be  assigned  during  toolkit 

construction. 

ALIASES:  None. 
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TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Parsed  Input 

DESCRIPTION:  A  collection  of  "words"  extracted  from  the  user 
input.  The  "words"  are  selected  in  such  a  manner  as  to 
enable  the  construction  of  a  response  to  the  user  request. 
For  example,  the  user  input  will  be  parsed  into  words  that 
identify:  1)  identification  of  the  input  data  (files) 

necessary  to  process  the  user  request,  2)  identification  of 
the  output  data  (files)  necessary  to  store  data  and  messages 
resulting  from  the  request,  and  3)  parameters  necessary  to 
configure  toolkit  components  in  a  manner  to  ensure  user- 
selected  component  options  are  implemented. 

SOURCES:  CUS32 

DESTINATIONS:  CUS33 

COMPOSITION:  A  collection  of  "words"  and  phrases  extracted 

from  the  user  input. 

DATA  CHARACTERISTICS:  Binary  representations  of  characters 

(ASCII)  or  numbers. 

ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Output  Data  &  Msgs 

DESCRIPTION:  Data  and  messages  generated  by  the  toolkit  when 
performing  the  tasks  necessary  to  respond  to  a  user's 
request. 

SOURCES:  CUS33 
DESTINATIONS:  User  terminal 

Disk  files 

Computer  peripherals  attached  to  the  support 
computer  or  to  the  user  terminal. 

COMPOSITION:  Data  generated  by  toolkit  components,  stored 

in  toolkit-accessible  disk  files  or  in  toolkit  or  system- 
level  variables,  and  messages  generated  by  toolkit 
components . 

PART  OF:  Data  &  Msgs 

DATA  CHARACTERISTICS:  All  data  and  messages  are  composed 
of  binary  representations  of  characters  (ASCII)  or  numbers. 
ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Response  Codes 

DESCRIPTION:  Codes  which  identifies  the  completion  status 

of  each  task  generated  during  a  response  to  a  user  request. 
If  a  task  or  tasks  were  not  successfully  completed,  then  the 
code  should  identify  the  individual  reasons  for  failure. 
SOURCES:  CUS33 

DESTINATIONS:  CUS34 

COMPOSITION:  Codes  identifying  the  success  or  failure  of 
each  toolkit  task  generated  in  response  to  a  user  request. 
DATA  CHARACTERISTICS:  Binary  representations  of  characters 

(ASCII)  or  numbers. 

VALUES:  TBD  -  Response  codes  to  be  assigned  during  toolkit 
construction. 

ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Response  Stats 

DESCRIPTION:  These  are  statistics  developed  during  the 

toolkit  response  to  a  user  input. 

SOURCES:  CUS33 

DESTINATIONS:  CUS34 

COMPOSITION:  Statistics  concerning:  1)  individual  component 
execution  times,  2)  errors  detected  during  component 
execution,  3)  status  of  support  computer  resources  at  the 
beginning  and  end  of  each  component  execution  and  4)  status 
of  the  toolkit  resources  at  the  beginning  and  end  of  each 
component  execution. 

PART  OF:  Toolkit  Mgt  Data 

DATA  CHARACTERISTICS:  All  statistics  are  composed  of 

binary  representations  of  characters  (ASCII)  or  numbers. 
Ideally,  the  statistics  will  be  represented  as  a  collection 
of  unique  names  with  appropriate  codes  or  frequencies 
attached  to  each  name  as  the  result  of  the  current  response. 
ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Analysis  Msgs 

DESCRIPTION:  Messages  generated  during  the  analysis  of  the 

toolkit  response  to  the  last  user  request.  These  messages 
provide  the  user  with  feedback  concerning  toolkit  responses 
during  their  toolkit  session  and  also  act  as  input  entries 
into  the  session  "history". 

SOURCES:  CUS34 

DESTINATIONS:  User  Terminal  Disk  Files 

COMPOSITION:  Message  describing  the  analysis  of  a  toolkit 

response  to  a  user  request. 

PART  OF:  Data  &  Msgs 

Templog  Entry 

DATA  CHARACTERISTICS:  All  messages  are  composed  of  binary 
representations  of  characters  (ASCII)  or  numbers. 

ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Storage  Request 

DESCRIPTION:  A  three-component  indicator  that  the  user  wishes 

to  have  data  currently  residing  in  temporary  storage  moved 
to  the  toolkit  permanent  storage  area. 

SOURCES:  CUS41 
DESTINATIONS:  CUS42 

COMPOSITION:  Contains  three  parts:  The  date/time  of  the 

request,  the  unique  user  id  of  the  user  requesting  the 
storage  transfer,  and  the  name  of  the  data  that  is  to  be 
moved.  The  request  is  contained  on  a  single  line  with  each 
component  separated  by  a  single  space. 

DATA  CHARACTERISTICS:  All  requests  are  composed  of  binary 
representations  of  characters  (ASCII)  or  numbers. 

ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Usage  Stats 

DESCRIPTION:  These  are  statistics  developed  during  a  a 

particular  user  session  which  are  provided  to  the  user  at 
the  end  of  the  session.  The  intention  is  to  provide  the 
user  with  a  "snapshot"  of  the  session  and  the  resources 
required  during  the  session. 

SOURCES:  CUS42 

COMPOSITION:  Although  the  actual  collection  of  statistics 

may  vary  at  the  request  of  the  user,  as  a  minimum  the 
following  statistics  will  be  provided:  1)  component 
selection  frequencies,  2)  The  total  number  of  errors 
detected  during  user  inputs,  3)  status  of  support  computer 
resources  at  the  beginning  and  end  of  the  toolkit  session 
and  4)  status  of  the  toolkit  resources  at  the  beginning  and 
end  of  the  toolkit  session. 

PART  OF:  Msgs 

DATA  CHARACTERISTICS:  All  statistics  are  composed  of 

binary  representations  of  characters  (ASCII)  or  numbers. 
Ideally,  the  statistics  will  be  represented  as  a  collection 
of  unique  names  with  appropriate  codes  or  frequencies 
attached  to  each  name  as  the  result  of  this  analysis. 

ALIASES:  None. 


TYPE:  DATA  ELEMENT 
DATE:  10  October  1984 

NAME:  Close  Messages 

DESCRIPTION:  Messages  generated  during  the  closing  of  the 

toolkit.  These  are  messages  sent  to  the  user  reporting  that 
the  toolkit  has  been  successfully  closed  and  that  control  is 
being  returned  to  the  support  computer  operating  system. 
SOURCES:  CUS44 

DESTINATIONS:  User  terminal 

COMPOSITION:  Messages  generated  by  the  custodian. 

PART  OF:  Msgs 

DATA  CHARACTERISTICS:  All  messages  are  composed  of  binary 
representations  of  characters  (ASCII)  or  numbers. 

ALIASES:  None. 


Appendix  B:  Structure  of  A  Prototype  AFIT  VLSI  CAD  Toolkit 

Prototype  Implementation  of  Toolkit  Drawer  Structure 
Using  UNIX  Hierarchical  Directories 

A  prototype  implementation  of  the  VLSI  CAD  toolkit 
drawer  structure  has  been  accomplished  on  the  AFIT  VAX 
11/780  computer.  This  AFIT  computer  system  employs  the  UNIX 
operating  system  which  permits  the  construction  of  hier¬ 
archical  disk  directories.  The  directory  feature  of  UNIX 
was  exploited  to  create  a  toolkit  whose  drawers  are  actually 
UNIX  directories.  The  drawer-to-UNIX  directory  mappings  for 
each  toolkit  compartment  are  shown  below.  The  directory 
hierarchy  is  presented  in  the  next  section. 


TOOLKIT  COMPONENT  NAME 

UNIX  DIRECTORY  NAME 

VLSI  CAD  TOOLKIT 

vlsi_tool_kit 

MANAGEMENT  TOOLS 

DRAWERS 

mgt_tools 

Configuration 

configuration 

Data  Translation 

data_transl 

Resource  Management 

resource_mgt 

Data  Analysis 

data_ana lysis 

Documentation  Management 

doc_mgt 

Environmental  Control 

environ_ctrl 

Data  Archival 

data_archival 

Data  Access  Control 

data_access 

Data  Security 

data_security 

Data  Storage  Management 

data_s to_mgt 

Report  Generation 

report_gen 
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MANAGEMENT  TOOLS  (Contd.) 
Standards  Management 
Library  Management 
Schedule  Management 


stands_mgt 
lib_mgt 
sched  mgt 


TOOLKIT  COMPONENT  NAME 

DESIGN  TOOLS 
DRAWERS 

Architectural 

Logic 

Floorplan 

Layout 

Interconnection 
Topological  Analysis 
Extraction 
Timing  Analysis 
Electrical  Analysis 
Mask  Data  Generation 
Design  Verification 
Design  Presentation 
Utilities 


UNIX  DIRECTORY  NAME 
design_tools 

architecture 

logic 

floorplan 

layout 

connection 

topoanalysis 

extraction 

timing_analy 

elect_analy 

mask_data_gen 

design_verify 

design_present 

utilities 


INFORMATION  STORAGE 
DRAWERS 


info  storage 


TEMPORARY  STORAGE 
DRAWER 


temp_storage 

temp_doc 
temp_libs 
temp  stats 


Documentation 

Libraries 

Statistics 


TEMPORARY  STORAGE  (Contd.) 

Schedules 

Design  Data 

Source  Code 

Aux  Data 


temp_sched 
temp_data 
temp_sources 
temp_aux  data 


TOOLKIT  COMPONENT  NAME 

PERMANENT  STORAGE 
DRAWER 

Documentation 
Libraries 
Statistics 
Schedules 
Design  Data 
Source  Code 


UNIX  DIRECTORY  NAME 
perm_storage 

perm_doc 

perm_libs 

perm_stats 

perm_sched 

perm_data 

perm_sources 

perm_aux_data 


Aux  Data 


The  hierarchical  srtucture  of  the  of  VLSI  CAD  toolkit 


is  shown  in  the  diagram  that  follows.  The  lines  connecting 
directories  or  groups  of  directories  represent  a  change  in 
level  to  that  directory  (group).  Directories  listed  without 
intervening  lines  are  at  the  same  level. 

The  highest  level  directory  is  the  "vlsi_tool_kit" 
level.  The  toolit  custodian  should  "reside"  at  the  highest 
level  directory  in  the  toolkit  structure. 

A  prototype  directory  structure  is  represented  by  the 
diagram  that  follows. 


vlsi  tool  kit 


mgt  tools 


I 

info_storage 


design_tools 


configuration 

data_transl 

resource_mgt 

data_ana lysis 

doc  mgt 

envTron_ctrl 

data_archival 

data_access 

data_security 

data_sto_jngt 

report_gen 

stands_mgt 

lib_mgt 

sched  mgt 


temp  storage 

“I 

temp_doc 

temp_libs 

temp_stats 

temp_sched 

temp_data 

temp_sources 

temp_aux__data 


I 

perm  storage 

"I 

perm_doc 

perm_l  ibs 

perm_stats 

perm_sched 

perm_data 

perm_sources 

perm_aux_data 


architecture 

logic 

f loorplan 

layout 

connection 

topoanalysis 

extraction 

timing_analy 

elect_analy 

mask_data_gen 

design_verify 

design_present 

utilities 


The  UNIX  "C-Shell"  Script  Used  to  Build  The  Toolkit  Hier- 
archical  Directory  Structure 


#  UNIX  C-SHELL  Script  to  build  hierarchical  directories  for  the 

♦  VLSI  CAD  TOOL  KIT  (drawers) 

* 

♦  Written  bys  Capt  Thomas  R.  Vermillion 

*  AFIT/EN  :  GE84D 

*  1  October  1984 

# 

* 

echo  '  ' 

echo  'VLSI  CAD  TOOLKIT  DIRECTORY  CONSTRUCTION  SCRIPT  V  1.0' 
echo  '  ' 

echo  -n  'Creating  Main  Toolkit  Directory  ...  ' 

#  main  tool  kit  directory  -  custodian  lives  here 
mkdir  vlsi_tool_kit 

chmod  go+rxw  vlsi_tool_kit 
echo  ' DONE ' 

echo  -n  'Creating  Major  Drawer  Directories  ...  ’ 

# 

cd  vlsi_tool_kit 

#  major  drawer  sections 

* 

mkdir  mgt_tools 
mkdir  info_storage 
mkdir  design_tools 
chmod  go+rwx  * 
echo  'DONE' 

echo  -n  'Creating  Individual  Management  Tool  Directories.  ' 

# 

♦management  tools  drawers 
cd  mgt_tools 

♦individual  management  tools 

♦ 

mkdir  configuration 
mkdir  data_transl 
mkdir  resource  mgt 
mkdir  data_anaTysis 
mkdir  doc_mgt 
mkdir  environ_ctrl 
mkdir  data_archival 
mkdir  data_access 
mkdir  data_security 
mkdir  data_stor_mgt 
mkdir  report_gen 
mkdir  stands_mgt 
mkdir  lib_mgt 
mkdir  sched_mgt 
chmod  go+rwx  * 
echo  'DONE' 

echo  -n  'Creating  Information  Storage  Directories  ...  ' 

♦ 

cd  . . 


cd  info_storage 

#  information  storage  drawers 

* 

mkdir  temp_storage 
cd  temp_storage 
mkdir  temp_doc 
mkdir  temp_libs 
mkdir  temp_stats 
mkdir  temp_sched 
mkdir  temp_data 
mkdir  temp_sources 
mkdir  temp_aux_data 
chmod  go+rwx  * 
cd  . . 

mkdir  perm_storage 
cd  perm_storage 
mkdir  perm_doc 
mkdir  perm_libs 
mkdir  perm_stats 
mkdir  perm_sched 
mkdir  perm_data 
mkdir  perm_sources 
mkdir  perm_aux_data 
chmod  g+rwx  * 
cd  . . 

chmod  g+rwx  * 
echo  'DONE' 

echo  -n  'Creating  Individual  Design  Tool  Directories  .. 

# 

cd  •  • 

cd  design_tools 

# 

mkdir  architecture 
mkdir  logic 
mkdir  floorplan 
mkdir  layout 
mkdir  connection 
mkdir  topoanalysis 
mkdir  extraction 
mkdir  timing_analy 
mkdir  elect_analy 
mkdir  mask_data_gen 
mkdir  design_verify 
mkdir  design  present 
mkdir  utilitTes 
chmod  g+rwx  * 
cd  . . 
cd  . . 

echo  'DONE' 
echo  '  ' 

echo  'VLSI  CAD  Toolkit  Directory  Construction  Completed 


Distribution  of  AF I T  I C  CAD  Tools  in  the  Prototype 
VLSI  CAD  Toolkit 


Distribution  of  existing  CAD  tools  into  their  appro¬ 
priate  toolkit  drawers  is  one  of  the  major  tasks  associated 
with  toolkit  integration.  This  step  has  been  performed  for 
the  AFIT  CAD  tools  and  the  results  are  presented  below.  The 
results  are  presented  on  a  drawer-by-drawer  basis  begiining 
at  the  top  of  the  toolkit  hierarchy.  The  tools  are  identi¬ 
fied  by  using  the  complete  UNIX  pathname  CURRENTLY  assigned 
to  the  tools  on  the  AFIT  VAX  11/780. 

DRAWER:  VLSI  CAD  Toolkit 
UNIX  DIRECTORY:  vlsi_tool_kit 
-  TOOL  LIST  - 
custodian 


DRAWER:  Management  Tools  Drawers 

UNIX  DIRECTORY:  mgt_tools 
-  TOOL  LIST  - 


DRAWER:  Configuration 

UNIX  DIRECTORY:  configuration 

-  TOOL  LIST  - 


DRAWER:  Data  Translation 

UNIX  DIRECTORY:  data_transl 
-  TOOL  LIST  - 
/usr/ local/cad/bin/cif 2ca 
/usr/ local/cad/bin/clipcif 
/usr/ local/cad/bin/clman 
/usr/ local /cad/ bin/ ca2db 
/usr/ local /cad/bin/ucf ilt 
/usr/local/cad/bin/db2cif 
/usr/ loca 1 /cad/ bin/ pres im 
/usr/ local /cad/ bin/ for for 
/ usr / loca 1 /cad /bin/ simf il ter 
/ usr / loca 1 /cad /bin/ spcpp 
/usr/local/cad/bin/rsort 
/usr/ loca 1/ cad/ bin/ window 
/usr/local/cad/bin/sim2 spice 
/ usr / loca 1 /cad /bin/ pspice 
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DRAWER:  Data  Translation 

UNIX  DIRECTORY:  data_transl 
-  TOOL  LIST  -  (Contd.) 

/usr/local/cad/uw/bin/netlist 
/ usr/ local/ cad/uw/bin/presim 
/usr/ local/cad/uw/bin/spcpp 
/usr/ local/cad/uw/bin/pspice 
/usr/local/cad/uw/bin/ca2db 
/usr/ local/cad/uw/bin/simf ilter 
/usr/local/cad/uw/bin/spice2g6 
/usr/ local/cad/uw/bin/ forfor 
/ usr/ local/cad/uw/bin/prescp 

/usr /local /cad/ stanford/src/ PI PELINE8 3/ SRC/ BANE/ window 
/usr/local/cad/stanford/src/PIPELINE83/SRC/BANE/xy2co 
/usr/ local/cad/s tanford/src/PIPELINE83 /SRC/ BANE/ concat 
/usr/local/cad/stanford/src/PIPELINE83/SRC/BANE/err2co 
/usr/ local /cad/ stanford/src/ PI PELINE83/ SRC/ RPLOT/b lockout 
/usr / local /cad/ stanford/src/ PIPELINE8 3/ SRC/ RPLOT/ convert 
/usr/ local /cad/ Stanford/ src/PIPELINE8 3/ SRC/ RPLOT/merge 
/usr / local /cad/ stanford/src /PI PELINE8 3/ SRC/ RPLOT/ rplt_wd.bin 
/usr/local/cad/stanford/src/PIPELINE83/SRC/RPLOT/unconvert 
/usr / local /cad/ stanf ord/ src/ PIPELINE83/ SRC/ RPLOT/ rsort 
/usr/local/cad/stanford/src/PIPELINE83/ SRC/ RPLOT/ window 
/usr/ local /cad/ Stanford/ src/ PIPELINE83/ SRC/CIFLOAD/cifar 
/usr/local/cad/stanford/src/PIPELINE83/ SRC/CIFLOAD/ cif load 
/usr / local /cad/ stanf ord/ src/ PIPELINE8 3/ SRC/CIFLOAD/ seif load 
/usr/ local /cad/ Stanford/ src/ PIPELINE83/ SRC/CIFLOAD/ splitfile 

/ usr/ local/cad/bin/blara 
/usr/ local/cad/bin/cifout-cat 
/usr/local/cad/bin/convert 
/usr/ local/cad/bin/ splitfile 
/usr/local/cad/bin/unconvert 
/usr/ local/cad/bin/rtsyms 
/usr/ local/cad/bin/cif cat 
/usr/ local/cad/uw/bin/xsimspc 


DRAWER:  Resource  Management 
UNIX  DIRECTORY:  resource_mgt 
-  TOOL  LIST  - 


DRAWER:  Data  Analysis 

UNIX  DIRECTORY:  data_analysis 

-  TOOL  LIST  - 

/usr / local /cad/ bin/cifs tat 


DRAWER:  Documentation  Management 

UNIX  DI FACTORY:  doc_mgt 

-  TOOL  LIST  - 

/usr/ local/cad/bin/cadman 

/usr/ local/cad/uw/bin/man 

/usr/ local /cad/uw/bin/whatis 


DRAWER:  Documentation  Management 

UNIX  DIRECTORY:  doc  mgt 

-  TOOL  LIST  -  (ContcL ) 

/usr/ local/ cad/ uw/ lib/ what is 
/usr/ local/cad/uw/man/MAKE 

DRAWER:  Environmental  Control 

UNIX  DIRECTORY:  environ_ctrl 

-  TOOL  LIST  - 


DRAWER:  Data  Archival 

UNIX  DIRECTORY:  data_archival 

-  TOOL  LIST  — 

/usr/ local /cad/bin/cif load 
/usr/ local/cad/bin/cifar 
/usr/local/cad/uw/lib/libutil .a 


DRAWER:  Data  Access  Control 
UNIX  DIRECTORY:  data_access 
-  TOOL  LIST  - 


DRAWER:  Data  Security 

UNIX  DIRECTORY:  data_security 

-  TOOL  LIST  - 


DRAWER:  Data  Storage  Management 

UNIX  DIRECTORY:  data_sto_mgt 
-  TOOL  LIST  - 
/usr/ local/cad/bin/dir 


DRAWER:  Report  Generation 
UNIX  DIRECTORY:  report_gen 
-  TOOL  LIST  - 


DRAWER:  Standards  Management 
UNIX  DIRECTORY:  stands_mgt 
-  TOOL  LIST  - 


DRAWER:  Library  Management 

UNIX  DIRECTORY:  lib_mgt 
-  TOOL  LIST  - 

/usr/ local /cad/bin/cif load 
/usr/ local/cad/bin/cifar 
/usr/local/cad/uw/lib/libutil .a 
/usr/ local/cad/lib/earl/lib  status 


DRAWER:  Schedule  Management 

UNIX  DIRECTORY:  sched_mgt 
-  TOOL  LIST  - 


DRAWER:  Design  Tools  Drawers 
UNIX  DIRECTORY:  design_tools 
-  TOOL  LIST  - 


DRAWER:  Architectural 
UNIX  DIRECTORY:  architecture 
-  TOOL  LIST  - 


DRAWER:  Logic 

UNIX  DIRECTORY:  logic 

-  TOOL  LIST  - 

/usr/ local /cad/bin/plasort 
/usr/local/cad/bin/eqntott 
/ usr/ local/cad/bin/mkpla 
/usr/ local/cad/bin/presto 
/usr/local/cad/bin/peg 
/usr/ local/cad/bin/plagen 
/usr/ local/cad/bin/plague 
/usr/local/cad/bin/changeo 
/usr/local/cad/bin/tpla 
/usr/ local/cad/bin/quilt 
/usr/ local /cad/ bin/ solve 
/usr/ local/cad/uw/bin/ presto 

/ us r / 1 oca 1 / cad / Stanford/ s rc / PLAGEN/ PLAGUE / p 1 ague 
/ usr/ local/cad/bin/plaid 
/usr/local/cad/bin/mintopla 


DRAWER:  Floorplan 

UNIX  DIRECTORY:  floorplan 

-  TOOL  LIST  - 


DRAWER :  Layout 

UNIX  DIRECTORY:  layout 

-  TOOL  LIST  ~ 

/usr/ local/cad/bin/bane 
/usr /local /cad/ bin/bane. old 
/usr/local/cad/bin/plap 
/usr/ local/cad/bin/cll 
/usr/ local /cad/bin/cl 12 
/usr/ local /cad/bin/ earl 
/usr/ local /cad/bin/c lay 
/usr/ local/cad/uw/bin/plap 
/ usr /local/ cad/ uw/ bin/ plap3 


DRAWER:  Layout 

UNIX  DIRECTORY:  layout 

-  TOOL  LIST  -  (Contd.) 

/usr/ loca 1/ cad/ stanford/src/ bane 

/usr/ local/cad/stanford/src/PIPELINE83/SRC/CLL2/cll2 
/usr/ local /cad/ stanford/src/ PI PELINE8 3 /SRC/BANE/bane 


DRAWER:  Interconnection 

UNIX  DIRECTORY:  connection 
-  TOOL  LIST  - 


DRAWER:  Topological  Analysis 

UNIX  DIRECTORY:  topoanalysis 

-  TOOL  LIST  - 

/usr/ local/cad/bin/ lyra 

/usr/ local/cad/bin/rulec 

/usr/ local/cad/bin/drcscript 

/usr/local/cad/bin/alldrc 

/usr/ local/cad/bin/f astdrc 

/usr/local/cad/bin/drc/bin_and 

/usr/ local /cad/bin/drc/bin_andnot 

/usr/local/cad/bin/drc/bin_chk 

/usr/local/cad/bin/drc/bin_coal 

/usr/ local/cad/bin/drc/bin_con 

/usr/local/cad/bin/drc/bin_err 

/usr/ local /cad/bin/drc/bin_exp 

/usr/local/cad/bin/drc/bin_filter 

/usr/local/cad/bin/drc/bin_gen 

/usr/local/cad/bin/drc/bin_hasnone 

/usr/ local /cad/bin/drc/bin_hassome 

/usr/ local/cad/bin/ drc/bin_or 

/usr/ local /cad/bin/drc/ciftorect 

/usr/ local/cad/bin/drc/drc .back 

/usr/local/cad/bin/drc/drcdoc 

/usr/local/cad/bin/drc/drcscript 

/usr/local/cad/bin/drc/edgetocif 

/usr/ local /cad/bin/drc/erc7 

/usr / local /cad/bin/drc/mult 

/usr/ local/cad/bin/drc/oldmerge 

/usr/local/cad/bin/drc/recttocif 

/usr/ local /cad/bin/drc/sedscript 

/usr/ local/ cad/bin/drc/enddrc 

/usr/local/cad/bin/drc/add94s 

/usr/ loca 1 /cad/ lib/bane/drc 

/usr/ local /cad/ lib/bane/drc/drc_f ilter .bak 

/usr/local/cad/lib/bane/drc/drc . 1 

/usr/ local /cad/ lib/ bane/ drc/drc.cmos 

/usr/local/cad/lib/bane/drc/drc. doc 

/usr/ loca 1/ cad/ 1 ib/bane/drc / drc .nmos 

/usr/ local /cad/ lib/bane/drc/drc_f ilter 

/usr/ loca 1/ cad/ lib/ bane/ drc/drcmask .doc 

/usr /local /cad/ lib/bane/drc/drco Id. sa 


DRAWER:  Topological  Analysis 
UNIX  DIRECTORY:  topoanalysis 
-  TOOL  LIST  -  (Contd.) 

/usr /local /cad/ lib/bane/drc/butconexp 
/usr/local/cad/lib/bane/drc/butcondrop 
/usr/ local /cad/ lib/bane/drc/frontsort 
/usr/ local /cad/ lib/bane/drc/fullexp 
/usr/ local/cad/ lib/bane/drc/ impchk 
/usr/local/cad/lib/bane/drc/ornmos 
/usr /local /cad/ lib/bane/drc/nmosextr 
/usr/ local /cad/ lib/bane/drc/ rectexp 
/usr /local /cad/ lib/bane/drc/rmbutcon 
/usr/ local/cad/ lib/bane/drc/ sepdpch 
/usr/ local/cad/ lib/bane/drc/sepchk 
/usr/ local/cad/ lib/bane/drc/ sepdpbur 
/usr/ local /cad/ lib/bane/drc /tranburied 
/usr/ local/cad/ lib/bane/drc/ trpol 
/usr/ local/cad/ lib/bane/drc/trdiff 
/usr/ local/cad/ lib/bane/drc/cmosextr 
/usr/ local/cad/ lib/bane/drc/csort 
/usr/ local /cad/ lib/bane/drc/diodechk 
/usr/ local/cad/ lib/bane/drc/ isect_exc 
/usr/ local/cad/ lib/bane/drc/orcmos 
/ usr/ local/cad/ lib/bane/drc/pnbuttcon 
/usr/ local/cad/ lib/bane/drc/pplusdiff 
/usr/ local/cad/ lib/bane/drc/pwellchk 
/ us r / 1 oca 1 / cad/ 1 ib / bane / dr c / tr and i f f 
/ us r / 1 oca 1 / cad / 1 ib / bane / dr c / two in t_exc 
/usr/ local/cad/ lib/bane/drc/bool 
/usr/ local/cad/ lib/bane/drc/boolf 
/usr/ local/cad/ lib/bane/drc/bsort 
/usr/ local/cad/ lib/bane/drc/conv 
/usr/ local/cad/ lib/bane/drc/cover 
/usr/ loca 1 / cad/ 1 ib/ bane/drc / exp 
/usr/ local/cad/ lib/bane/drc/errout 
/usr/ local/cad/ lib/bane/drc/expand 
/usr/ local/cad/ lib/bane/drc/ intersect 
/usr/ local /cad/ lib/bane/drc/ separate 
/usr/ local/ cad/ lib/bane/drc/sepone 
/usr/ local /cad/ lib/ bane/drc/ shrink 
/usr/ local/cad/ lib/bane/drc/ tranexp 
/usr/ local/cad/ lib/bane/drc/ twocover 
/usr/local/cad/bin/clldrc. lib 
/usr / loca 1/cad/bin/clldrc. lib/boo 1 
/usr/local/cad/bin/clldrc. lib/atot 
/usr/local/cad/bin/clldrc. lib/ bool f 
/usr/local/cad/bin/clldrc. lib/ bsort 
/usr/local/cad/bin/clldrc. lib/btoa 
/usr/local/cad/bin/clldrc. lib/butconexp 
/usr/ local/cad/bin/cl ldrc . lib/conchk 
/usr/local/cad/bin/clldrc. lib/concov 
/usr/ local / cad/bin/cl ldrc . 1 ib/consep 
/usr/local/cad/bin/clldrc. lib/ conv 
/usr/local/cad/bin/clldrc. lib/ dbl 


DRAWER:  Topological  Analysis 

UNIX  DIRECTORY:  topoanalysis 
-  TOOL  LIST  -  (Contd.) 

/usr/local/cad/bin/clldrc. lib/ drcfi Iter 
/usr/ local /cad/bin/clldrc . lib/ exp 
/usr/local/cad/bin/clldrc. lib/ extr 
/usr/local/cad/bin/clldrc. lib/ fron tout 
/usr/local/cad/bin/clldrc. lib/ frontsort 
/usr/local/cad/bin/clldrc. lib/ fullexp 
/usr/local/cad/bin/clldrc. lib/ impchk 
/usr/ local/cad/bin/cl ldrc . lib/minwidth 
/usr/local/cad/bin/clldrc. lib/ordrc 
/usr/local/cad/bin/clldrc. lib/ pi 
/usr/ local/cad/bin/cl ldrc . lib/rectexp 
/usr/local/cad/bin/clldrc. lib/ rmbutcon 
/usr/local/cad/bin/clldrc. lib/ sepchk 
/usr/local/cad/bin/clldrc. lib/ sepdpch 
/usr/local/cad/bin/clldrc. lib/ tranexp 
/usr/local/cad/bin/clldrc. lib/ trpol 
/usr/ local/cad/bin/cl ldrc . 1 ib/widchk 
/usr/ local/cad/uw/bin/drcscript 
/usr/ local/cad/uw/bin/drcpgms 
/usr/local/cad/uw/bin/drcpgms/bin_and 
/usr/ local /cad/uw/bin/drcpgms/bin_andnot 
/ usr/ loca 1 / cad/ uw/bin/drcpgms /bin_chk 
/usr/ local/cad/uw/bin/drcpgras/bin_coal 
/usr/local/cad/uw/bin/drcpgras/bin_con 
/usr/ local /cad/uw/bin/drcpgms/bin_err 
/usr/local/cad/uw/bin/drcpgms/bin_exp 
/usr/ local /cad/uw/bin/drcpgras/bin_fil ter 
/usr/ local/cad/uw/bin/drcpgms /bin_gen 
/usr/local/cad/uw/bin/drcpgms/bin_hasnone 
/usr/ local /cad/ uw/bin/drcpgms /bin_hassome 
/usr/ local /cad/ uw/bin/drcpgms /bin_or 
/usr/local/cad/uw/bin/drcpgms/cif torect 
/usr/local/cad/uw/bin/drcpgms/recttocif 
/usr /local /cad/ uw/bin/drcpgms /edge tocif 
/usr/local/cad/uw/bin/add94s 
/usr/ local/cad/uw/bin/enddrc 
/usr/ local /cad/ uw/bin/drc 

/usr/ local/cad/stanford/src/DRC83/drc.cmos 
/usr/local/cad/stanford/src/DRC83/drc_filter 
/usr/local/cad/stanford/src/DRC83/drc . 1 
/usr /local /cad/ Stanford/ src/DRC8 3/ Makefile 
/usr/local/cad/stanford/src/DRC83/drcold.sa 
/usr/local/cad/stanford/src/DRC83/butconexp 
/usr/ local /cad/ stanford/src/DRC83/butcondrop 
/usr/local/cad/stanford/src/DRC83/drc.nmos 
/usr/ local/cad/stanford/src/DRC83/drc.doc 
/usr/ local /cad/stanford/src/DRC8 3/ frontsort 
/usr/ local /cad/ Stanford/ src/DRC83/ fullexp 
/ usr / loca 1 /cad/ Stanford/ src/DRC8 3 /impchk 
/usr/ local/cad/stanford/src/DRC83/ornmos 
/usr/ local /cad/ Stanford/ src/DRC8 3 /nmosextr 


DRAWER:  Topological  Analysis 
UNIX  DIRECTORY:  topoanalysis 
-  TOOL  LIST  -  (Contd.) 

/usr/local/cad/stanford/src/DRC83/rectexp 
/usr/ local /cad/ Stanford/ src/DRC8 3 /rmbutcon 
/usr/local/cad/stanford/src/DRC83/sepdpch 
/usr/local/cad/stanford/src/DRC83/sepchk 
/usr/local/cad/stanford/src/DRC83/sepdpbur 
/usr/local/cad/stanford/src/DRC83/ tranburied 
/usr/ local /cad/ Stanford/ src/DRC8 3 /trpol 
/usr/local/cad/stanford/src/DRC83/trdiff 
/usr /local /cad/ s tanf ord/ src/DRC83/cmosextr 
/usr/local/cad/stanford/src/DRC83/csort 
/usr/local/cad/stanford/src/DRC83/diodechk 
/usr /local/ cad/ stanford/src/DRC83/isect_exc 
/usr /local /cad/ Stanford/ src/DRC83/orcmos 
/usr/local/cad/stanford/src/DRC83/pnbuttcon 
/usr/local/cad/stanford/src/DRC83/pplusdif f 
/usr/ local /cad/ Stanford/ src/DRC83/pwellchk 
/usr /local /cad/ stanford/src/DRC83/drcmask. doc 
/usr/local/cad/stanford/src/DRC83/trandiff 
/usr /local /cad/ Stanford/ src/DRC83/twoint_exc 
/usr /local /cad/ stanford/src/DRC83/bool 
/ us r / 1 oca 1 / cad / s t an f or d / s r c / DRC8 3 / boo 1 f 
/usr /local/ cad/ stanford/src/DRC83/bsort 
/usr /local /cad/ Stanford/ src/DRC83/conv 
/ us r / 1 oca 1 / cad / s tanf ord / s rc / DRC8 3 / cover 
/usr/local/cad/stanford/src/DRC83/exp 
/usr/ local /cad/ stanford/src/DRC83/errout 
/usr/ local /cad/ Stanford/ src/DRC83/expand 
/usr/local/cad/stanford/src/DRC83/ inter sect 
/ us r / 1 oca 1 / cad / s tanf ord / s rc / DRC8 3 / separ a te 
/usr/local/cad/stanford/src/DRC83/sepone 
/usr/local/cad/stanford/src/DRC8 3/ shrink 
/usr /local /cad/ s tanf ord/ src/DRC83/tranexp 
/usr/ loca 1 /cad/ s  tanf ord/ s  rc/ DRC8  3 / twocover 


DRAWER:  Extraction 
UNIX  DIRECTORY:  extraction 
-  TOOL  LIST  - 
/usr/local/cad/bin/mextra 
/usr/ local /cad/bin/ net list 
/usr/ local /cad/bin/cif plot 


DRAWER:  Timing  Analysis 
UNIX  DIRECTORY:  timing_analy 
-  TOOL  LIST  - 
/usr / loca 1/cad/bin/crystal 
/usr/ local /cad/ bin/ rnl 
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DRAWER:  Electrical  Analysis 

UNIX  DIRECTORY:  elect_analy 
-  TOOL  LIST  - 
/usr/ local/cad/bin/powest 
/usr/ local/cad/bin/erc 
/usr/ local/cad/bin/ercscript 
/usr/ local/cad/uw/bin/ ere 
/usr/ local /cad/uw/bin/ercscript 


DRAWER:  Mask  Data  Generation 

UNIX  DIRECTORY:  mask_data_gen 
-  TOOL  LIST  “ 

/usr/ local /cad/bin/c 11 
/usr/local/cad/bin/cll2 
/usr/ local /cad/bin/cif plot 


DRAWER:  Design  Verification 
UNIX  DIRECTORY:  design_verify 
-  TOOL  LIST  - 
/usr/ local /cad/bin/esim 
/usr/local/cad/bin/spice2g6 
/usr / local /cad/bin/ spice 
/usr/ local/cad/bin/crystal 
/usr/ local/cad/bin/rnl 
/usr/local/cad/uw/bin/rnl 


DRAWER:  Design  Presentation 

UNIX  DIRECTORY:  design_present 
-  TOOL  LIST  - 

/usr/ local /cad/bin/cif plot 
/usr/local/cad/bin/fastcif 
/usr/ local/cad/bin/ vdrap 
/usr/ local/cad/bin/print 
/usr/local/cad/bin/vpltdmp 
/usr/local/cad/bin/rrplot 
/usr/local/cad/bin/penplot 
/usr/local/cad/bin/vdump 
/usr/ local /cad/bin/mcp 
/usr/local/cad/uw/bin/vic 
/usr/ local/cad/uw/bin/ 7221 
/usr/ local/cad/uw/bin/ 7580 
/usr/ local /cad/uw/bin/penplot 
/usr/local/cad/uw/bin/mtp 

/usr/ local /cad/ Stanford/ sre/ PI PELINE8 3/ SRC/ APLOT/aplot 
/usr/ local /cad/stanford/src/PIPELINE83/SRC/RPLOT/ rrplot 
/usr/local/cad/stanford/src/PIPELINE83/SRC/RPLOT/ tplot 
/ usr /local /cad/ bin/ listnode 
/usr /local /cad/ bin/ mdump 
/usr/ local/cad/bin/ 7221 
/usr/local/cad/bin/rrplot .bin 
/usr/ local/cad/bin/ listesym 


DRAWER:  Design  Presentation 

UNIX  DIRECTORY:  design_present 
-  TOOL  LIST  -  (Contd.) 

/usr/ local /cad/bin/mprint 
/usr/ local/cad/uw/bin/ lspice 
/usr/ local /cad/bin/vlsifont 
/usr/local/cad/bin/dbdi 
/usr/ local/cad/bin/pattern 
/usr/ local/cad/bin/patternl 


DRAWER:  Utilities 

UNIX  DIRECTORY:  utilities 

-  TOOL  LIST  - 

/usr/ local/cad/bin/uc 

/usr/ local/cad/bin/chksum 

/usr/local/cad/bin/tvitest 

/usr/ local/cad/bin/ inuse 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CLL2/TEST 

/usr/local/cad/bin/sleeper 

/usr/local/cad/bin/vprm.old 

/usr/local/cad/bin/rsleeper 

/usr/ local /cad/bin/inter 

/usr/ local/cad/bin/ ic 

/usr/local/cad/bin/cater 

/usr/ local/cad/bin/xsimspc 

/usr/ local/cad/bin/cif 

/usr/ local /cad/bin/merge 

/usr/local/cad/ uw/ bin/ apropos 

/usr/ local/cad/bin/mas 

/usr/ local/cad/bin/cmem 

/usr/local/cad/bin/smm 

/usr/local/cad/bin/CI 

/usr/ local/cad/bin/smp 

/usr/ local/cad/bin/ srae 

/usr/ local/cad/bin/rootd 

/usr/local/cad/bin/xx 

/usr /local/cad/uw/bin/ status 

/usr/ local/cad/uw/bin/pattern 

/usr/local/cad/uw/bin/patternl 

/usr/local/cad/uw/bin/reset_om 

/usr/local/cad/uw/bin/status_om 

/usr/ local/cad/uw/bin/ scope 

/usr/ local /cad/ uw/bin/pass2 


DRAWER:  Information  Storage  Drawers 

UNIX  DIRECTORY:  info__storage 
-  TOOL  LIST  - 
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DRAWER:  Temporary  Storage  Drawer 

UNIX  DIRECTORY:  temp_storage 
-  TOOL  LIST  - 


DRAWER:  Documentation 
UNIX  DIRECTORY:  temp_doc 
-  TOOL  LIST  - 


DRAWER:  Libraries 

UNIX  DIRECTORY:  temp_libs 

-  TOOL  LIST  - 


DRAWER:  Statistics 

UNIX  DIRECTORY:  temp_stats 

-  TOOL  LIST  - 


DRAWER:  Schedules 

UNIX  DIRECTORY:  temp_sched 

-  TOOL  LIST  - 


DRAWER:  Design  Data 

UNIX  DIRECTORY:  temp_data 
-  TOOL  LIST  - 
/usr/local/cad/sos/sos 
/usr/local/cad/test/ciffile.cif 
/usr/ local/cad/ test/ pla.cll 
/usr/ local /cad/ test/ spla.cif 
/usr/ local /cad/ test/pla .cif 
/usr/local/cad/test/ciffile.drc 
/usr/local/cad/test/ciffile.log 
/usr/ local/cad/test/pla .nodes 
/usr /local /cad/ test /pla.sim 
/usr/ local /cad/ test/pla. names 
/usr/ local /cad/ test/pla. cap 
/usr/ local/ cad/ test/pla . spice 


DRAWER:  Source  Code 

UNIX  DIRECTORY:  temp_sources 

-  TOOL  LIST  - 


DRAWER:  Aux  Data 

UNIX  DIRECTORY:  temp_aux_data 

-  TOOL  LIST  - 


DRAWER:  Permanent  Storage  Drawer 

UNIX  DIRECTORY:  perm_storage 
-  TOOL  LIST  - 


DRAWER:  Documentation 

UNIX  DIRECTORY:  perm_doc 

-  TOOL  LIST  - 

/usr/ local/cad/uw/doc 

/usr/local/cad/uw/doc/whj .let 

/usr/local/cad/uw/doc/Makef ile 

/usr/ local/cad/uw/doc/cel Is 

/usr/local/ cad / uw/ doc / READ_ME 

/usr/local/cad/uw/doc/netlist 

/usr/ local/cad/uw/doc/plap 

/usr/ local/cad/uw/ doc/make .out 

/usr/local/cad/uw/doc/presim 

/usr/ local/cad/uw/ doc/src 

/usr/ local/cad/uw/doc/ src/ intro . tblms 

/usr /local /cad/uw/doc/ src/ READ__ME 

/usr/ local/cad/uw/ doc/src/cells .tblms 

/usr/local/cad/uw/doc/src/spice.tbleqnms 

/ usr / 1 oca 1 / cad / uw/ doc / src / READ_ME_UW 

/usr /local/cad/uw/ doc/ src/presim. ms 

/usr/local/cad/uw/doc/src/netlist.ms 

/usr/ local/cad/uw/ doc/src/rnl. ms 

/usr/local/cad/uw/doc/src/rnlbrief .ms 

/usr/ local/cad/uw/doc/ src/plap. tblms 

/usr/local/cad/uw/doc/src/plapsrc 

/usr/ local/cad/uw/doc/ src/plapsrc/Makef ile 

/usr/local/cad/uw/doc/src/plapsrc/plap.O 

/usr/ local/cad/uw/ doc/ src/plapsrc/READ_ME 

/usr/ local/cad/uw/doc/src/plapsrc/ plap. 1 

/usr/local/cad/uw/doc/src/plapsrc/plap.2 

/usr/local/cad/uw/doc/src/plapsrc/plap.3 

/usr /local/cad/uw/doc/src/plapsrc/ plap. 4 

/usr/ local/cad/uw/doc/src/plapsrc/ plap. 5 

/usr /local/cad/uw/doc/src/plapsrc/ plap. 6 

/usr/ local/cad/uw/ doc/src/plapsrc/plap. 7 

/usr /local/cad/uw/doc/src/plapsrc/ plap. 8 

/usr/ local/cad/uw/doc/ src/plapsrc/plap. 9 

/usr /local/cad/uw/doc/src/plapsrc/ plap. macros 

/usr /local/cad/uw/doc/ src/ cell src 

/usr /local /cad/uw/ doc/ src/cellsrc/READ_ME 

/usr/ local /cad/uw/doc/ src/ cell src/ cel lTb. 3 

/usr/ local /cad/uw/doc/ src/ cell src/ Makefile 

/usr/local/cad/uw/doc/src/cellsrc/cellib.O 

/usr /local /cad/uw/doc/ src/ cell src/cellib.l 

/usr /local /cad/uw/doc/ src/ cell src /cel lib. 2 

/usr / local / cad/uw/doc/ src/ce 11 src/cel lib. 4 

/usr/local/cad/uw/doc/src/cellsrc/cell .macros 

/usr/ local/cad/uw/doc/ src/ layout . tblms 

/usr/ local /cad/uw/doc/ src/ title .ms 

/usr/local/cad/uw/doc/rnlbrief 


DRAWER:  Documentation 

UNIX  DIRECTORY:  perm_doc 
-  TOOL  LIST  -  (Contd.) 

/ usr / loca 1 / cad/ uw/doc / intro 
/usr/ local/cad/uw/doc/ layout 
/usr/ local/cad/uw/doc/spice 
/usr/local/cad/uw/doc/whj . let .bak 
/usr /local /cad/ uw/doc/ title 
/usr/local/cad/man 
/usr/local/cad/man/catl 
/usr/ local/cad/man/catl/cadman.l 
/usr/ local/cad/ man/catl/peg. 1 
/usr/ local/cad/man/catl/uc . 1 
/usr / local / cad/man/catl/ cif plot .1 
/usr/local/cad/man/catl/vdump.l 
/usr/ local/cad/man/catl/chksum. 1 
/usr/ local /cad/man/catl/cif . 1 
/ usr / loca 1/ cad/ man/ catl/cif 2ca.l 
/usr/local/cad/man/catl/cifar .1 
/usr/ local /cad/man/catl/cif load. 1 
/usr/ local /cad/man/catl/cif stat . 1 
/usr/ local/cad/man/catl/clipcif . 1 
/usr/ local/cad/man/catl/cll . 1 
/usr/ local/cad/ man/catl/cl ldrc . 1 
/usr/ local/cad/man/catl/crystal . 1 
/usr/ local/cad/man/catl/eqntott . 1 
/usr/ local/cad/man/catl/esim. 1 
/usr/ local /cad/raan/catl/ intro . 1 
/usr/ local/cad/man/catl/ lyra . 1 
/usr/local/cad/man/catl/mcp.l 
/usr/local/cad/man/catl/mextra.l 
/usr/ local /cad/man/catl /mkpla . 1 
/usr/local/cad/man/catl/plagen.l 
/usr/ local /cad/man/catl/plague.l 
/usr/ local/cad/man/ catl/clay . 1 
/usr/local/cad/raan/catl/quilt.l 
/usr/local/cad/man/catl/rsort . 1 
/usr/ local/cad/man/catl/rulec . 1 
/usr/ local/cad/man/catl/sim2spice . 1 
/usr/ local/cad/man/catl/ tpla.l 
/usr/ local/cad/man/catl/ucf il t . 1 
/usr / local /cad/man/catl/ vlsifont . 1 
/usr/local/cad/man/catl/window.l 
/usr/local/cad/man/ catl/blam.l 
/usr/ local /cad/man/catl/ pres to . 1 
/usr/ local /cad/man/catl/clman. 1 
/usr/local/cad/man/catl/dir.l 
/usr/ local/cad/man/catl/ solve . 1 
/usr/ local/cad/man/catl/ar . 1 
/usr/ local/cad/man/cat2 
/usr/local/cad/man/cat3 
/usr/local/cad/man/cat3/tpack.3 
/usr /local /cad /man/ cat 4 
/usr/ loca l/cad/man/cat5 


DRAWER:  Documentation 

UNIX  DIRECTORY:  perm_doc 
-  TOOL  LIST  -  (Contd.) 

/usr/ local/cad/man/cat5/cadrc . 5 
/usr/ local/cad/man/cat5/cif out . 5 
/usr/ local /cad/man/cat5/ intro . 5 
/usr/ local/cad/man/cat5/ tpla . 5 
/usr/ local /cad/ man/ manl 
/usr/local/cad/man/manl/ rulec.l 
/usr/ local/cad/man/manl/ lyra . 1 
/usr/  local/cad/man/uianl/crystal .  1 
/usr/local/cad/man/manl/cadman. 1 
/usr/local/cad/man/manl/solve .1 
/usr/local/cad/man/manl/esim.l 
/usr/ local/cad/man/manl/ vlsifont . 1 
/usr/ local /cad/man/manl/chksum . 1 
/usr/ local /cad/man/manl/quilt . 1 
/usr /local /cad/ man/ manl/ tpla. 1 
/usr/local/cad/man/manl/intro.l 
/usr/local/cad/man/manl/ucfilt .1 
/usr/ local/cad/man/manl/clipcif . 1 
/usr/ local /cad/ man/ manl/cifs tat . 1 
/usr/ local/cad/man/manl/mextra. 1 
/usr/local/cad/man/manl/mkpla. 1 
/usr/ local/cad/man/manl/cif 2ca. 1 
/usr/ loca 1 / cad/ man/ manl / mcp . 1 
/usr/ local/cad/man/manl/cif plot . 1 
/usr/ loca 1 / cad/ man/ manl / ar . 1 
/usr/local/cad/man/manl/peg.l 
/usr/ loca 1 / cad/ man/ manl / eqntott . 1 
/usr/ local/cad/man/manl/ sim2spice . 1 
/usr /local /cad/ man/ manl/ vdump.l 
/usr/ local/cad/man/manl/cif .1 
/usr/ local/cad/man/manl/cif ar . 1 
/usr/ local/cad/man/manl/cif load . 1 
/usr/local/cad/man/manl/cll .1 
/usr / loca 1/cad/man/manl/clldrc.l 
/usr/ loca 1/cad/man/manl/plagen. 1 
/usr/ local/cad/man/manl/plague . 1 
/usr/local/cad/man/manl/rsort . 1 
/usr/local/cad/man/manl/window.l 
/usr/local/cad/man/manl/presto. 1 
/usr/local/cad/man/manl/blam.l 
/ usr/ local /cad/ man/ manl /dir . 1 
/usr/ local/cad/man /manl/clman . 1 
/usr/local/cad/man/manl/uc.l 
/usr/ local/cad/man/ manl/ c lay .1 
/usr/ local/cad/man/manl/cif ar . sav 
/usr/local/cad/man/manl/powest.li 
/usr/ local/cad/man/ manl/erc . li 
/usr/ local /cad/ man/ manl/ spcpp.li 
/usr/local/cad/man/man5 
/usr/ local/cad/man/man5/cadrc . 5 
/usr /local /cad/ man/ man5 /tpla. 5 


DRAWER;  Documentation 
UNIX  DIRECTORY;  perm_doc 
-  TOOL  LIST  -  (Contd.) 

/ usr/ local/cad/man/man5/ intro . 5 
/usr/local/cad/man/man5/cifout. 5 
/usr/local/cad/man/tmac 
/usr/ local /cad/ man/ tmac/ tmac . anc . prnt 
/usr/ local /cad/ man/ tmac/ReadMe 
/ usr/ loca 1 /cad/ man/ tmac/ tmac . anc 
/usr/local/cad/man/tmac/ tmac. anc .new 
/usr/local/cad/man/man3 
/usr/local/cad/man/man3/tpack. 3 
/usr / local /cad/man/man. proto 
/usr/ local / cad/ man/ save . man 
/usr/local/cad/man/man4 
/usr/ local/ cad/ uw/ man 
/usr/local/cad/uw/man/manl 
/usr/local/cad/uw/man/manl/mexnodes . li 
/usr/ local/cad/uw/man/manl/drc . li 
/usr/ local/cad/uw/man/manl/erc . li 
/usr/ local/cad/uw/man/manl/spice . li 
/usr/ local/cad/uw/man/manl/penplot . li 
/usr/ loca 1/ cad/ uw/ man/ manl/ laytools . li 
/usr/local/cad/uw/man/manl/mtp.li 
/usr/local/cad/uw/man/manl/db2cif .li 
/usr/local/cad/uw/man/manl/presim.li 
/usr/local/cad/uw/man/manl/plap.li 
/usr/ local/cad/uw/man/manl/pspice . li 
/usr/ local /cad/uw/man/manl/ vie . li 
/usr/ local/cad/uw/man/manl/simfi Iter .li 
/usr/ local /cad/uw/man/manl/ca2db.li 
/usr/ local /cad/uw/man/manl/ reset_om.l 
/usr/ local /cad/ uw/ man/ manl/ simtoo Is .li 
/usr/local/cad/uw/man/manl/presto. li 
/usr/local/cad/uw/man/manl/rnl .li 
/usr/ local/cad/uw/man/manl/ spcpp. li 
/ usr / 1 oca 1 / cad/ uw/ man/ manl/netlist.li 
/usr/ local/cad/uw/man/manl/nl . li 
/usr/local/cad/uw/man/man3 
/usr/local/cad/uw/man/man3/om. 3 
/usr/ local/cad/uw/man/man3/om_driver . 3 
/usr/local/cad/uw/man/man3/om_dmacros .3 
/usr/local/cad/uw/man/man3/om_omacros .3 
/usr/local/cad/uw/man/man3/status_om.3 
/usr/ local/cad/uw/man/man3/om_example . 3 
/usr/ local/cad/uw/ man/man5 
/usr/local/cad/uw/man/man5/tec. 5i 
/usr/local/cad/uw/man/man5/simfile.5i 
/usr/ loca l/cad/uw/man/man5/ techno logy .5i 
/usr/ local/cad/uw/man/Man . proto 
/usr/local/cad/uw/man/READ_ME 
/usr/local/cad/uw/man/catl 
/usr/ local /cad/uw/man/catl/ pi ap. li 
/usr/ local /cad/uw/man/catl/cif plot .li 


DRAWER:  Documentation 

UNIX  DIRECTORY:  perm_doc 
-  TOOL  LIST  -  (Contd.) 

/usr/ local /cad/uw/man/catl/rnl . li 

/usr/local/cad/uw/man/catl/presto. li 

/usr /local /cad/ uw/man/catl/presim.li 

/usr/ local /cad/uw/man/catl/drc . li 

/usr/ local /cad/ uw/man/catl/ca2db . li 

/usr/ local/cad/uw/man/catl/mexnodes . li 

/usr/ loca 1/cad/uw/man/catl/net list .li 

/usr/ local/cad/uw/man/catl/penplot . li 

/usr/ local/cad/uw/man/catl/db2cif . li 

/usr/ local /cad/uw/man/catl/ spice . li 

/usr/ local /cad/ uw/man/catl/pspice . li 

/usr/local/cad/uw/man/catl/laytools . li 

/usr/ local /cad/uw/man/catl/ vie . li 

/usr/ local/cad/uw/man/catl/erc . li 

/usr/ local /cad/uw/man/catl/reset_om.l 

/usr/ local/cad/uw/man/catl/ tpla . li 

/usr/ loca 1/cad/uw/man/catl/mtp.li 

/usr/local/cad/uw/man/cat3 

/ usr/ loca 1 / cad/ uw/ man/ ca t 3 / epa th . 3 i 

/usr/ local/cad/uw/ man/cat5 

/usr/ local/cad/uw/ man/cat5/ tech. 5i 

/usr/local/cad/uw/man/cat5/tec.5i 

/usr/ loca l/cad/uw/man/cat5/ technology ,5i 

/usr/ local/cad/uw/man/cat5/simf ile . 5i 

/usr/local/cad/uw/CONTENTS 

/usr/local/cad/uw/README 

/usr/local/cad/uw/directory 

/usr/ local/cad/uw/ lib/tmac/VLSIman. tmac 

/usr/ local/cad/ lib/ear 1/cpads .doc 

/usr/ local/cad/ lib/earl/npads .doc 

/usr/local/cad/stanford/src/DRC83/READ  ME 

/usr/ local /cad/ Stanford/ src/PIPELINE837READ_ME 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CIF/READ_ME 

/usr/ local /cad/ Stanford/ sre/ PI PELINE83/SRC/CIFLOAD/READ_ME 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CIFLOAD/cifar .1 

/usr/local/cad/stanford/src/PIPELINE83/ SRC/CLL2/D0C 

/usr /local /cad/ Stanford/ arc/ PIPELINE8 3/ SRC/CLL2/READ_ME 

/usr/local/cad/stanford/src/PIPELINE83/SRC/APLOT/READ_ME 

/usr/local/cad/stanford/src/PIPELINE83/SRC/RPLOT/READ_ME 

/usr/ local /cad/ Stanford/ src/PLAGEN/PLA/pla . 1 

/usr/local/cad/stanford/src/PLAGEN/PLA/lex. 1 

/usr/local/cad/stanford/src/PLAGEN/PLAGUE/plague. 1 

/usr/ local/cad/stanford/src/PLAGEN/PLAGUE/plague. 1 


DRAWER:  Libraries 

UNIX  DIRECTORY:  perm_libs 

-  TOOL  LIST  - 

/usr/ local/cad/ lib 

/usr/ local/ cad/ lib/s_ext .ell 

/usr/ iocal/cad/mosis 


DRAWER:  Libraries 

UNIX  DIRECTORY:  perm_libs 

-  TOOL  LIST  -  (Contd.) 

/usr/local/cad/mosis/40p69x68 .cif 

/usr/local/cad/mosis/40p69x68 . list 

/usr/ local/cad/mosis/ 64p69x68 .cif 

/usr/local/cad/mosis/64p69x68 .list 

/usr/ local /cad/ lib/ lyra 

/usr/ local /cad/ lib/ lyra/nmosBERK . r 

/usr/ local /cad/ lib/ lyra/cmos-pwJPL.r 

/usr/ local /cad/ lib/ lyra/nmosBERK 

/usr/ local /cad/ lib/ lyra/ Lyra . proto 

/usr/ local /cad/ lib/ lyra/nmosMC . r 

/usr /local /cad/ lib/ lyra/ Ruled 

/usr/ local/cad/ lib/ lyra/DEFAULTS 

/usr/ local/cad/ lib/ tpla 

/usr/ local/cad/ lib/tpla/ Makefile 

/usr/local/cad/lib/tpla/p-Tcis . tp 

/usr/ local/cad/ lib/ tpla/ p-Mtrans . tp 

/usr/local/cad/lib/tpla/p-Mcis . tp 

/usr/ local/cad/ lib/ tpla/p-Btrans . tp 

/usr/ local/cad/ lib/ tpla/p-Bcis . tp 

/usr/ local/cad/ lib/ tpla/ ReadMe 

/usr /local /cad/ lib/ tpla/p.tp 

/usr/ local/cad/ lib/ tpla/p-Ttrans . tp 

/usr/ local/cad/ lib/quilt 

/usr/ local/cad/ lib/quilt/q-vlsifont . tp 

/usr/ local/cad/ lib/slang 

/usr/ local/cad/ lib/slang/simmacs.l 

/usr/ local/cad/ lib/slang/ try3.1 

/usr/ local/cad/ lib/slang/ try2 . 1 

/usr/local/cad/lib/slang/tryl . 1 

/usr/ local /cad/ lib/ slang/ sproject .1 

/usr /local /cad/ lib/ slang/ sirascr . 1 

/usr /local/cad/ lib/ slang/ jkf macs. 1 

/usr/local/cad/lib/slang/slang.spec.h 

/usr/ local/cad/ lib/ext .ell 

/usr/ local/cad/ lib/displays 

/ usr/ local/cad/ lib/ tpack . 1 ib 

/usr /local /cad/ lib/ tpack.h 

/usr/ local/cad/ lib/extname 

/usr/ local/cad/ lib/tf ill 

/usr/ local/cad/ lib/uf ill 

/usr/ local /cad/ lib/ vf ill 

/usr/ local/cad/ lib/hp 

/usr/local/cad/lib/trilog 

/usr/ local /cad/ lib/mcpl 

/usr/ local/cad/ lib/cifwindow 

/usr/ local/cad/ lib/cif flatten 

/usr/ local/cad/ lib/ fix. 6 

/usr/ local/cad/ lib/ pat. unknown 

/usr/ local/cad/ lib/ pat .nmos 

/usr/ local/cad/ 1 ib/ pa t.j pi 

/usr/ local /cad/ lib/ pat .cmos . info 
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DRAWER:  Libraries 

UNIX  DIRECTORY:  perm_libs 

-  TOOL  LIST  -  (Contd.) 

/usr/local/cad/mosis/ 40p69x68 .cif 

/ usr/ local /cad/mosis/ 40p69x6 8. list 

/usr/local/cad/mosis/64p69x68 .cif 

/usr/ local /cad/mosis/ 6 4p6 9x68 . list 

/usr/ local /cad/ lib/ lyra 

/usr/ local/cad/ lib/ lyra/nmosBERK . r 

/usr/ local/cad/ lib/ lyra/cmos-pwJPL.r 

/usr/ local/cad/ lib/ lyra/nmosBERK 

/usr/ local/cad/ lib/ lyra/ Lyra .proto 

/usr /local /cad/ lib/ lyra/nmosMC.r 

/usr/ local/cad/ lib/ lyra/Rulecl 

/usr/ local/cad/ lib/ lyra/DEPAULTS 

/usr/ local /cad/ lib/ tpla 

/usr /local /cad/ lib/ tpla/Makefile 

/usr/ local/cad/ lib/ tpla/p-Tcis . tp 

/usr/ local/cad/ lib/ tpla/p-Mtrans . tp 

/usr/ local/cad/ lib/ tpla/ p-Mcis . tp 

/usr/ local/cad/ lib/ tpla/ p-Btrans .tp 

/usr/ local/cad/ lib/ tpla/p-Bcis . tp 

/usr/ local/cad/ lib/ tpla/ ReadMe 

/usr/ local/cad/ lib/ tpla/p. tp 

/  usr  / 1  oca  1  /  cad  / 1  ib  / 1  p  1  a  /  p-T  trans .  tp 

/usr/ local/cad/ lib/quilt 

/usr/ local/cad/ lib/quilt/q-vlsif ont . tp 

/usr/ local /cad/ lib/ slang 

/usr/ local/cad/ lib/slang/simmacs.l 

/usr/ local/cad/ lib/slang/ try3 . 1 

/usr/ local/cad/ lib/slang/ try2 . 1 

/usr /local/cad/ lib/ slang/ tryl.l 

/usr /local /cad/ lib/ slang/ sproject.l 

/usr/ local/cad/ lib/ slang/ simscr.l 

/usr/ local/cad/ lib/ slang/ jkf macs . 1 

/usr /local /cad/ lib/ slang/ slang. spec. h 

/usr/ local/cad/ lib/ext.cll 

/usr/ local/cad/ lib/displays 

/ usr / loca 1 / cad/ lib/ tpack . 1 ib 

/usr/local/cad/lib/tpack.h 

/usr/ local/cad/ lib/extname 

/usr/ local/cad/ lib/ tf ill 

/usr/ local/cad/ lib/uf ill 

/usr/ local/cad/ lib/vf ill 

/usr/ local/cad/ lib/hp 

/usr / local /cad/ lib/tri log 

/usr/ local/cad/ lib/mcpl 

/usr/ local/cad/ lib/cifwindow 

/usr/ local /cad/ lib/cif flatten 

/usr /local /cad/ lib/ fix. 6 

/usr/ local /cad/ lib/ pat .unknown 

/usr/ local/cad/ lib/pat .nmos 

/ usr / local /cad/ lib/ pat. jpl 

/usr/ local/cad/ lib/ pat .cmos . info 
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DRAWER:  Libraries 

UNIX  DIRECTORY:  perm_libs 

-  TOOL  LIST  -  (Contd.) 

/usr/ local /cad/ lib/ pat .cmos 
/usr/ local/cad/ lib/extract 
/  usr / local /cad/ lib/extpass3 
/usr/local/cad/lib/PlaStaticIn.ne 
/usr/ local/cad/ lib/ log 
/usr/ local/cad/ lib/ 1 ibs . cif 
/usr/ loca 1 / cad/ 1 ib/ 1 ibs . 1 ib 
/usr/ local/cad/ lib/ libplap. a 
/usr/ local/cad/ lib/ tmac 
/usr/local/cad/lib/pshell .p 
/usr/ local/cad/ lib/s_ext . cl 1 .old 
/usr/ local/cad/ lib/save . tmp 
/usr /local /cad/ lib/ libs. lib. new 
/  usr / local/cad/ lib/ PlaStaticIn.ol 
/usr/ local/cad/uw/ lib/cel lib 
/usr/ local/cad/uw/ lib/cel lib/nmos 
/  usr / local/cad/uw/ lib/ cel lib/ nmos/ 2 8p23x34.att 
/usr /local/cad/uw/ lib/cel lib/nmos/ 28p23x34.ca 
/usr/local/cad/uw/lib/cellib/nmos/28p23x34.sym 
/usr/ local/cad/uw/lib/cellib/nmos/28p46x34.att 
/usr/ local/cad/uw/ lib/ cel lib/nmos/ 2 8p4 6x34 .ca 
/usr/local/cad/uw/lib/cellib/nmos/28p46x34.sym 
/usr/ local/cad/uw/ lib/cel lib/nmos/ 40p46x34.att 
/usr/local/cad/uw/lib/cellib/nmos/40p46x34.ca 
/usr /local/cad/uw/ lib/cel lib/ nmos/ 40p46x34.sym 
/  usr/ loca 1 / cad/ uw/ 1 ib/ ce 1 1 ib/ nmos/ 40p46x6  8 . att 
/  usr/ local/cad/uw/ lib/cel lib/nmos/ 40p46x68.ca 
/usr/ local/cad/uw/ lib/cel lib/nmos/ 40p46x68.sym 
/usr/ local/cad/uw/ lib/cel  Ij.b/nmos/40p69x68. att 
/usr/ local/cad/uw/ lib/cel lib/nmos/ 40p69x68 .ca 
/  usr / loca 1 /cad/ uw/ 1 ib/ce 1 1 ib/ nmos / 4 0p6 9x6 8 . sym 
/usr /local/cad/uw/ lib/cel lib/ nmos/ 64p46x68.att 
/  usr/ local /cad/uw/1  ib/ce  Hib/nmos/64p46x6  8.  ca 
/usr/ local/cad/uw/ lib/cel lib/nmos/ 64p46x68 . sym 
/usr/local/cad/uw/lib/cellib/nmos/64p69x68.att 
/usr/local/cad/uw/lib/cellib/nmos/64p69x68.ca 
/usr/local/cad/uw/lib/cellib/nmos/64p69x68.sym 
/usr/local/cad/uw/lib/cellib/nmos/64p79x92.att 
/  usr /local /cad/uw/1 ib/cel lib/nmos/ 64p79x9 2. ca 
/usr/local/cad/uw/lib/cellib/nmos/64p79x92 .sym 
/  usr/ local /cad/uw/ lib/cel lib/ nmos/ 84p6 9x6 8 .att 
/usr/local/cad/uw/lib/cellib/nmos/84p69x68.ca 
/usr / loca 1 /cad/uw/ 1 ib/cel lib/nmos/ 84p6 9x6 8. sym 
/usr/ local/cad/uw/ 1 ib/ce Hib/nmos/84p79x92. att 
/usr/ local/cad/uw/ lib/cel lib/nmos/ 8 4p79x9 2 .ca 
/usr / loca 1 /cad/uw/ 1 ib/ce 1 lib/ nmos/ 8 4p79x92. sym 
/usr/local/cad/uw/lib/cellib/nmos/ClkLogic.att 
/usr /local /cad/uw/1 ib/ce Ilib/nmos/ClkLogic.ca 
/  usr / loca 1 /cad/uw/ 1 ib/cel lib/nmos/ClkLogic. sym 
/usr/local/cad/uw/lib/cellib/nmos/PLAbin.att 
/usr/local/cad/uw/lib/cellib/nmos/PLAbin.ca 


DRAWER:  Libraries 

UNIX  DIRECTORY:  perm_libs 

-  TOOL  LIST  -  (Contd.) 

/usr/ local /cad/uw/lib/cellib/nmos/PLAbin.sym 
/usr/ local/cad/uw/ lib/cel lib/nmos/PLAbout.att 
/usr/local/cad/uw/lib/cellib/nmos/PLAbout .ca 
/ usr / local/cad/uw/ 1 ib/ce 1 lib/ nmos/ PLAbout. sym 
/usr/local/cad/uw/lib/cellib/nmos/PLAbpllp.att 
/ usr / local /cad/uw/ 1 ib/ce 1 lib/ nmos /PLAbpllp.ca 
/usr/ local /cad/uw/lib/cellib/nmos/PLAbpllp.sym 
/usr/ loca 1 / cad/ uw/ lib/cellib/ nmos / PLAce 1 1 . a tt 
/usr /local/cad/uw/ lib/cel lib/ nmos/PLAcell.ca 
/usr/ loca 1 / cad/ uw/ 1 ib/ ce 1 1 ib/ nmo  s / PLAce 1 1 . sym 
/usr/ local/cad/uw/ lib/cellib/nmos/PLAcon.att 
/usr/ loca 1 / cad/uw/ 1 ib/ cell ib/ nmos / PLAcon . ca 
/usr/ loca 1 /cad/ uw/ 1 ib/ce 1 1 ib/ nmos/ PLAcon . sym 
/usr/local/cad/uw/lib/cellib/nmos/PLAground.att 
/usr/ loca 1 / cad/ uw/ 1 ib/ ce 1 1 ib/ nmos / PLAground . ca 
/usr/ loca 1 / cad/uw/ lib/cellib/ nmos / PLAground .sym 
/usr / local/cad/uw/ lib/cel lib/ nmos/PLAin.att 
/ usr / local /cad/uw/ lib/ cel lib/ nmos/ PLAin.ca 
/usr/local/cad/uw/lib/cellib/nmos/PLAin.sym 
/usr/ loca 1 / cad/uw/ 1 ib/ ce 1 1 ib/ nmos/ PLA j  og . a tt 
/usr /local /cad/uw/ lib/cel lib/nraos/PLA jog. ca 
/usr/local/ cad / uw/ 1 ib/ ce 1 1 ib/ nmos / PLA j  og . sym 
/usr /local /cad/uw/ 1 ib/ce llib/nmos/PLAmx jog. att 
/usr/ local/cad/uw/ lib/cellib/nmos/PLAmxjog.ca 
/usr/ loca 1 / cad/uw/ lib/cellib/ nmos / PLAmxj og . sym 
/usr/local/cad/uw/lib/cellib/nmos/PLAout.att 
/usr/ local/cad/uw/ lib/cel lib/ nmos/PLAout .ca 
/usr/ loca 1 / cad/uw/ 1 ib/ ce 1 1 ib/ nmos / PLAout . sym 
/usr/local/cad/ uw/ lib/cellib/ nmos / PLApl 1 p . a t t 
/ usr / local /cad/uw/ 1 ib/ce 1 lib/ nmos/ PLApllp.ca 
/usr /local /cad/uw/ lib/ cel lib/ nmos /PLApl Ip. sym 
/usr/local/cad/uw/lib/cellib/nmos/PLAspace.att 
/usr/ loca 1 /cad/uw/ 1 ib/ ce 1 1 ib/ nmos / PLAspace . ca 
/usr /local /cad/uw/ lib/cel lib/ nmos/ PLAspace. sym 
/usr/local/cad/uw/lib/cellib/nmos/PLAtee.att 
/usr/ loca 1 / cad/uw/ lib/cellib/ nmos / PLAtee . ca 
/usr/ local/cad/uw/ lib/cel lib/ nmos/ PLAtee . sym 
/usr/ local/cad/uw/ lib/cel lib/nmos/Pad3State . att 
/usr /local /cad/uw/ 1 ib/ce llib/nmos/Pad3State.ca 
/usr/ local/cad/uw/ lib/cel lib/ nmos/ Pad3State . sym 
/usr /local /cad/uw/ 1 ib/ce 1 lib/ nmos/ PadBlank. att 
/usr/local/cad/uw/lib/cellib/nmos/PadBlank.ca 
/usr/ local/cad/uw/ lib/cel lib/ nmos/ PadBlank . sym 
/usr/local/cad/uw/lib/cellib/nmos/PadClkBar.att 
/ usr / loca 1 / cad/uw/ lib/ cel lib/ nmos/ PadClkBar.ca 
/ usr / loca 1 /cad/ uw/ 1 ib/ce 1 lib/ nmos /PadClkBar .sym 
/usr/local/cad/uw/lib/cellib/nmos/PadClkO.att 
/usr/local/cad/uw/lib/cellib/nmos/PadClkO.ca 
/usr/local/cad/uw/lib/cellib/nmos/PadClkO.sym 
/usr/ local /cad/uw/ 1 ib/ce 1 lib/ nmos /PadDriver .att 
/usr/ local/cad/uw/ lib/cel lib/ nmos /PadDriver . ca 


DRAWER:  Libraries 

UNIX  DIRECTORY:  perm_libs 

-  TOOL  LIST  -  (Contd.) 

/usr/local/cad/uw/lib/cellib/nmos/PadDriver .sym 
/ usr / loca 1 / cad/uw/ 1 ib/ ce 1 1 ib/nmos / PadGround . a tt 
/usr/local/cad/uw/lib/cellib/nmos/PadGround.ca 
/usr/ loca 1/cad/uw/ lib/cel lib/nmos/PadGround . sym 
/usr/ local /cad/uw/ lib/cel lib/nmos/Padln.att 
/usr/ loca 1/cad/uw/ 1 ib/cel lib/ nmos/ Padln.ca 
/usr/local/cad/uw/lib/cellib/nmos/Padln.sym 
/usr/local/cad/uw/lib/cellib/nmos/PadOut.att 
/usr / loca 1/cad/uw/ lib/cel lib/ nmos/ PadOut.ca 
/usr/ local/cad/uw/ lib/cel lib/nmos/PadOut .sym 
/usr/ loca 1 / cad/uw/ 1 ib/ce 1 1 ib/nmos/ PadVdd . a tt 
/usr/ local/cad/uw/ lib/cel lib/ nmos /PadVdd.ca 
/usr /loca 1/cad/uw/ lib/cel lib/ nmos/ PadVdd. sym 
/usr/local/cad/uw/lib/cellib/nmos/gb.att 
/usr/ local/cad/uw/ lib/cel 1 ib/nmos/gb . ca 
/usr/ local/cad/uw/ 1 ib/ce 1 1 ib/nmos/gb . sym 
/usr/local/cad/uw/lib/cellib/nmos/greast.att 
/usr /local /cad/uw/ lib/cel lib/ nmos/greast.ca 
/usr /loca 1/cad/uw/ lib/cel lib/ nmos/greast. sym 
/usr/ loca 1/cad/uw/ lib/cel lib/nmos/makef ile 
/usr/local/cad/uw/lib/cellib/nmos/nmos.doc 
/usr/local/cad/uw/lib/cellib/nmos/pulldownE.att 
/usr/local/cad/uw/lib/cellib/nmos/pulldownE.ca 
/usr/ local/cad/uw/ lib/cel lib/nmos/pul ldownE . sym 
/usr /loca 1/cad/uw/ lib/cel lib/nmos/pulldownN.att 
/usr /local /cad/uw/ lib/cel lib/nmos/pul ldownN.ca 
/usr /loca 1/cad/uw/ lib/cel lib/ nmos/pulldownN. sym 
/usr /loca 1/cad/uw/ lib/cel lib/nmos/pul ldownS.att 
/usr/local/cad/uw/lib/cellib/nmos/pulldownS.ca 
/ usr / local / cad/uw/ 1 ib/ce 11 ib/nmos/pulldownS. sym 
/usr/ local/cad/uw/ lib/cel lib/nmos/pul ldownW.att 
/usr/ local /cad/uw/ lib/cel lib/ nmos /pul ldownW.ca 
/usr/ local/cad/uw/ lib/cel 1 ib/nmos/pul ldownW. sym 
/usr/local/cad/uw/lib/cellib/nmos/rb.att 
/usr/local/cad/uw/lib/cellib/nmos/rb.ca 
/usr/local/cad/uw/lib/cellib/nmos/rb.sym 
/usr/local/cad/uw/lib/cellib/nmos/symboll.att 
/usr/ local/cad/uw/ lib/cellib/nmos/symboll.ca 
/ usr/ local/cad/uw/ lib/cel 1 ib/nmos/ symbol 1 . sym 
/usr/ local/cad/uw/ lib/cel lib/nmos/symbol3 .att 
/usr/ loca 1/cad/uw/ lib/cel lib/ nmos /symbol 3 .ca 
/usr/ local/cad/uw/ 1 ib/cel lib/ nmos /symbol 3 .sym 
/usr /loca 1/cad/uw/ 1 ib/cel lib/cmospw 
/usr/local/cad/uw/lib/cellib/cmospw/28p46x34.att 
/usr / loca 1 /cad/uw/ 1 ib/cel lib/cmospw/ 28p46x3 4. ca 
/usr/ local/cad/uw/ lib/ cel lib/cmospw/ 2 8p46x34. sym 
/usr / local /cad/uw/ 1 ib/cel lib/cmospw/2binttlbuf .att 
/usr /local/ cad/uw/ lib/cellib/cmospw/2binttlbuf .ca 
/usr/local/cad/uw/lib/cellib/cmospw/2binttlbuf .sym 
/usr / loca 1/cad/uw/ lib/cel lib/cmospw/ 40p46x68. att 
/usr/local/cad/uw/lib/cellib/cmospw/40p46x68.ca 


DRAWER:  Libraries 

UNIX  DIRECTORY:  perm_libs 

-  TOOL  LIST  -  (Contd.) 

/usr/ local /cad/uw/ Iib/cellib/cmospw/40p46x68. syro 
/usr/ local/cad/uw/ lib/cell ib/cmospw/ 40p69x68 .att 
/usr/ local/cad/uw/ 1 ib/ce 11 ib/cmospw/ 40p6 9x6 8 .ca 
/ usr / loca 1 /cad/uw/ lib/cellib/cmospw/40p6 9x6 8. sym 
/usr/ local /cad/uw/ lib/cel 1 ib/cmospw/ 64p6 9x6 8 .att 
/usr/ loca 1 /cad/uw/ 1 ib/cel 1 ib/cmospw/ 64p69x68 .ca 
/usr/local/cad/uw/lib/cellib/cmospw/64p69x68.sym 
/usr/local/cad/uw/lib/cellib/cmospw/64p79x92.att 
/usr/ local/cad/uw/ lib/cel lib/cmospw/ 64p79x92 .ca 
/usr/ loca 1 /cad/uw/ lib/cel lib/cmospw/ 64p79x9 2 .sym 
/usr/local/cad/uw/lib/cellib/cmospw/84p79x92.att 
/usr/local/cad/uw/lib/cellib/cmospw/84p79x92.ca 
/usr/ local/cad/uw/ 1 ib/cel lib/cmospw/ 8 4p79x9 2 . sym 
/usr/ local/cad/uw/ lib/cel lib/cmospw/_. att 
/usr/ local/cad/uw/ lib/cel lib/cmospw/_.ca 
/usr /local /cad/uw/ 1 ib/ce llib/cmospw/_. sym 

/usr /local /cad/uw/ lib/ cel lib/cmospw/ _ .att 

/usr/ local/cad/uw/ lib/cel lib/cmospw/ _ .ca 

/usr/ local/cad/uw/ lib/cel lib/cmospw/ _ .sym 

/usr/local/cad/uw/lib/cellib/cmospw/_arrest.att 
/usr /local /cad/uw/ 1 ib/cel lib/cmospw/_arrest.ca 
/usr/ local / cad/uw/ 1 ib/ce 1 1 ib/ cmospw/_arrest . sym 
/ usr/ local/cad/uw/ lib/cel lib/cmospw/_bin-buf .att 
/ usr / loca 1 / cad/uw/ 1 ib/ ce 1 1 ib/ cmospw/_bin-buf . ca 
/usr/ local /cad/uw/ lib/cel lib/cmospw/_bin-buf .sym 
/usr/ local/cad/uw/ lib/cel lib/cmospw/_bin-buf 2 .att 
/usr/ local /cad/uw/ 1 ib/cel lib/cmospw/_bin-buf 2.ca 
/usr/ local/cad/uw/ lib/cel 1 ib/cmospw/_bin-buf 2 . sym 
/ usr/ loca 1 /cad/uw/ 1 ib/ce 1 1 ib/ cmospw/_dm . att 
/usr /local /cad/uw/ 1 ib/cel lib/cmospw/_dm.ca 
/ usr/ local/cad/uw/ lib/cel lib/ cmospw/_dm. sym 
/usr/ local/cad/uw/ lib/cel lib/cmospw/_driveh. att 
/usr/ local/cad/uw/ 1 ib/ce 1 1 ib/cmospw /_driveh .ca 
/ usr/ loca 1 /cad/uw/ 1 ib/ce 1 1 ib/ cmospw/_dr i veh . sym 
/usr/ local /cad/uw/ 1 ib/ce llib/cmospw/_drivel .att 
/usr/ local/cad/uw/ lib/cel lib/cmospw/_drivel .ca 
/usr/ local /cad/uw/ 1  ib/ce  llib/cmospw/__drivel .  sym 
/usr/ local/cad/uw/ 1 ib/ce 1 lib/cmospw/_ga tel . att 
/ usr/ local/cad/uw/ lib/cel lib/cmospw/_ga tel .ca 
/usr/ local/cad/uw/ lib/cel lib/cmospw/_gatel .sym 
/usr /local /cad/uw/ 1 ib/cel lib/ cmospw/_gate2 .att 
/usr/local/cad/uw/lib/cellib/cmospw/_gate2.ca 
/usr/local/cad/uw/lib/cellib/cmospw/_gate2.sym 
/usr/ local /cad/uw/ 1 ib/ce llib/cmospw/_gate3 .att 
/usr/local/cad/uw/lib/cellib/cmospw/_gate3 .ca 
/usr/ local/cad/uw/ 1 ib/ce 1 lib/cmospw/_gate3 . sym 
/usr/ local/cad/uw/ lib/cel lib/cmospw/_gate4 .att 
/ usr / loca 1 /cad/uw/ 1 ib/ce llib/cmospw/_gate 4. ca 
/usr/ local/cad/uw/ lib/cellib/cmospw/_gate4 .sym 
/usr/ local/cad/uw/ 1 ib/cel lib/ cmospw/_gate5 . att 
/usr/local/cad/uw/lib/cellib/cmospw/_gate5.ca 
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/usr/ local/cad/uw/ 1 ib/ce 1 lib/ cmospw/_gate5 . sym 
/usr/ local/cad/uw/lib/cellib/cmospw/_gate7.att 
/usr/ local/cad/uw/ lib/cel lib/cmospw/_gate7 .ca 
/usr/ local/cad/uw/ lib/cel 1 ib/ cmospw/_gate7 . sym 
/usr/ local/cad/uw/lib/cellib/cmospw/_gate8.att 
/usr/ local/cad/uw/ 1 ib/cel lib/cmospw/_gate8 . ca 
/usr /local /cad/uw/lib/cellib/cmospw/_gate8 .sym 
/usr/ local/cad/uw/ 1 ib/cel lib/cmospw/_inpro . att 
/usr /local /cad/uw/ 1 ib/cel lib/cmospw/_inpro.ca 
/usr/ local/cad/uw/ 1 ib/cel 1 ib/cmospw/_inpro . sym 
/usr / local/cad/uw/ 1 ib/cel lib/cmospw/_out-buf .att 
/usr/local/cad/uw/ lib/cel lib/cmospw/_out-buf.ca 
/usr /local /cad/uw/ lib/cel lib/cmospw/_out-buf .sym 
/usr/local/cad/uw/lib/cellib/cmospw/_padpart.att 
/usr /local /cad/uw/ lib/cellib/cmospw/_padpart.ca 
/usr /local /cad/uw/ lib/cellib/cmospw/_padpart. sym 
/usr /local /cad/uw/ 1 ib/cel lib/cmospw/_plug. att 
/usr/local/cad/uw/lib/cellib/cmospw/_plug.ca 
/ usr/ local/cad/uw/ 1 ib/cel lib/cmospw/_plug . sym 
/usr/ local/cad/uw/ lib/cel lib/cmospw/_pm. att 
/usr /local /cad/uw/ 1 ib/cel lib/cmospw/_pm.ca 
/usr/local/cad/uw/lib/cellib/cmospw/_pm.sym 
/usr/ local/cad/uw/ lib/cel lib/cmospw/_pm2. att 
/usr /local /cad/uw/ lib/cellib/cmospw/_pm2.ca 
/usr/ local /cad/uw/ lib/cel lib/cmospw/_pm2 . sym 
/usr/ local/cad/uw/ lib/cel lib/croospw/_pm3. att 
/usr/ local/cad/uw/ lib/cel lib/ cmospw/_pm3.ca 
/usr/local/cad/uw/lib/cellib/cmospw/_pm3.sym 
/usr/ loca 1 /cad/uw/ 1 ib/ce 1 1 ib/cmospw/_pwt . att 
/ usr/ loca 1 / cad/ uw/ 1 ib/ce 1 1 ib/croospw/_pwt . ca 
/usr/ loca 1 / cad/uw/ 1 ib/ce 1 1 ib/croospw/_pwt . sym 
/usr /local /cad/uw/ lib/cellib/cmospw/_resistor .att 
/usr/local/cad/uw/lib/cellib/cmospw/_resistor .ca 
/usr/ local/cad/uw/ 1 ib/cel lib/ cmospw/_resis tor . sym 
/usr/ local/cad/uw/ lib/cel lib/cmospw/_tri-buf .att 
/usr/ local /cad/uw/ 1 ib/cel lib/cmospw/_tri-buf.ca 
/usr/ local/cad/uw/ lib/cel 1 ib/cmospw/_tri-buf . sym 
/usr/local/cad/uw/lib/cellib/cmospw/_ttl-driveh.at 
/usr/ local/cad/uw/ lib/cel lib/cmospw/_ttl-driveh.ca 
/usr/ local/cad/uw/ lib/cellib/cmospw/_ttl-driveh.sy 
/usr/ local /cad/uw/ lib/ cel lib/cmospw/binttlbuf .att 
/ usr/ local /cad/uw/ 1 ib/cel lib/ cmospw/binttlbuf.ca 
/usr/ local /cad/uw/ lib/cel lib/cmospw/binttlbuf .sym 
/usr/ local/cad/uw/ 1 ib/cel lib/cmospw/gb . att 
/usr/local/cad/uw/ lib/cel lib/cmospw/gb.ca 
/usr/ local /cad/uw/ 1 ib/cel lib/cmospw/gb. sym 
/usr/ local /cad/uw/ 1 ib/cel lib/cmospw/makef ile 
/usr/ local/cad/uw/ 1 ib/cel lib/ cmospw/outttlbuf . att 
/usr/ local/cad/uw/ lib/cel lib/cmospw/outttlbuf.ca 
/usr/local/cad/uw/ 1 ib/cel lib/cmospw/outttlbuf . sym 
/usr/ local/ cad/ uw/1 ib/ce llib/cmospw/padl .att 
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/usr/local/cad/uw/lib/cellib/cmospw/padl.ca 
/usr/ local /cad/uw/ 1 ib/cel lib/cmospw/padl . sym 
/usr/ local /cad/uw/ lib/cellib/cmospw/padlbin-ttl .at 
/usr/ local/cad/uw/ lib/cellib/cmospw/padlbin-ttl .ca 
/usr/ local/cad/uw/ lib/cellib/cmospw/padlbin-ttl .sy 
/usr /local /cad/uw/ lib/cellib/cmospw/padlbin.att 
/usr/ local/cad/uw/ 1 ib/cel lib/ cmospw/ padlbin.ca 
/usr/ local/cad/uw/ lib/cellib/cmospw/padlbin.sym 
/usr/local/cad/uw/lib/cellib/cmospw/padlgnd.att 
/usr /local /cad/uw/ lib/cel lib/ cmospw/padlgnd.ca 
/usr /local /cad/uw/ lib/cel lib/ cmospw/ padlgnd. sym 
/usr/ local/cad/uw/lib/cellib/cmospw/padlin.att 
/usr /local /cad/uw/ lib/ cel lib/cmospw/padlin.ca 
/usr/ local/cad/uw/lib/cellib/cmospw/padlin.sym 
/usr/ local /cad/uw/ 1 ib/cel lib/cmospw/padlout-ttl .at 
/usr/ local/cad/uw/ lib/cel lib/cmospw/padlout-ttl .ca 
/usr/ local/cad/uw/ lib/cel lib/cmospw/padlout-ttl .sy 
/usr /local /cad/uw/ lib/cellib/cmospw/padlout.att 
/usr/ local/cad/uw/ lib/cel lib/cmospw/padlout.ca 
/ usr / loca 1 / cad/uw/ 1 ib/ ce 1 1 ib/ cmospw/ padlout . sym 
/usr/local/cad/uw/lib/cellib/cmospw/padlspace.att 
/usr/ local/cad/uw/ lib/cel lib/ cmospw/ padlspace . ca 
/usr / local/cad/uw/ lib/cel lib/cmospw/padlspace. sym 
/usr/ local/cad/uw/ lib/cellib/cmospw/padlts.att 
/usr/ local/cad/uw/ lib/cel lib/cmospw/padlts . ca 
/usr/local/cad/uw/lib/cellib/cmospw/padlts.sym 
/usr/local/cad/uw/lib/cellib/cmospw/padlvdd.att 
/usr/ local/cad/uw/ lib/cel lib/cmospw/padlvdd.ca 
/usr/ local/cad/uw/ lib/cel lib/cmospw/padlvdd . sym 
/ usr /local /cad/uw/ lib/cellib/cmospw/pad2. a tt 
/usr/ loca 1 / cad/uw/ 1 ib/ ce 1 1 ib/ cmospw/ pad 2 . ca 
/usr/ local/cad/uw/ lib/cel lib/ cmospw/ pad2. sym 
/usr/ loca 1 /cad/uw/ 1 ib/cel 1 ib/cmospw/ pad2bin-tt 1 . at 
/usr /local /cad/uw/ 1 ib/cel lib/cmospw/pad2bin-ttl .ca 
/usr/ local/cad/uw/ 1 ib/cel lib/ cmospw/ pad2bin-ttl .sy 
/usr /local /cad/uw/ 1 ib/cel lib/ cmospw/pad2bin.att 
/usr/local/cad/uw/lib/cellib/cmospw/pad2bin.ca 
/usr/local/cad/uw/lib/cellib/craospw/pad2bin.sym 
/usr/ local/cad/uw/ 1 ib/cel lib/ cmospw/ pad2gnd . att 
/usr/ local/cad/uw/ 1 ib/cel lib/ cmospw/ pad2gnd .ca 
/usr/ local/cad/uw/ lib/cel lib/cmospw/pad2gnd . sym 
/usr/ local/cad/uw/ lib/cel lib/ cmospw/pad2in. att 
/usr/local/cad/uw/lib/cellib/cmospw/pad2in.ca 
/ usr /local /cad/uw/ lib/cel lib/cmospw/pad2in. sym 
/usr /local /cad/uw/ 1 ib/cel 1 ib/cmospw/ pad2space. att 
/usr/ local/cad/uw/ 1 ib/cel 1 ib/cmospw/ pad2 space .ca 
/usr/local/cad/uw/lib/cellib/cmospw/pad2space.sym 
/usr/ local/cad/uw/ lib/cel lib/cmospw/pad2vdd .att 
/ usr / loca 1 / cad / uw/ lib/cellib/ cmospw/ pad2 vdd . ca 
/usr/ local/cad/uw/ lib/cel lib/cmospw/pad2vdd. sym 
/usr/ local/cad/uw/ 1 ib/cel lib/ cmospw/ pad 3 .att 
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/ usr/ local /cad/uw/ lib/cel lib/cmospw/pad3 .ca 
/usr/ local /cad/uw/ lib/cellib/ cmospw/pad3 .sym 
/usr/ local/cad/uw/lib/cellib/cmospw/pad3gnd.att 
/usr/ local/cad/uw/ lib/cellib/cmospw/pad3gnd.ca 
/usr/ local /cad/uw/ 1 ib/cel lib/ cmospw/ pad3gnd. sym 
/ usr/ local /cad/uw/ 1 ib/cel lib/ cmospw/pad3 in. att 
/usr /local /cad/uw/ lib/cel lib/ cmospw/ pad3in.ca 
/usr/ local/cad/uw/ 1 ib/cel lib/ cmospw/pad3in. sym 
/usr/ local/cad/uw/ lib/cel lib/cmospw/pad3 space. att 
/usr/ loca 1 /cad/uw/ 1 ib/cel lib/cmospw/pad3space.ca 
/ usr/ loca 1 / cad/uw/ 1 ib/ cell ib/ cmospw/ pad3  space . sym 
/usr/ local / cad/uw/ 1 ib/cel 1 ib/cmospw/ pad3vdd . att 
/usr / local/cad/uw/ lib/cel lib/ cmospw/ pad3vdd.ca 
/usr/ local/cad/uw/ lib/cellib/ cmospw/pad3vdd . sym 
/usr/ local/cad/uw/ lib/cel lib/ cmospw/ project. att 
/usr /local /cad/uw/ lib/cel lib/ cmospw/ project.ca 
/usr/ local/cad/uw/ lib/cel lib/ cmospw/ project .sym 
/usr/ local/cad/uw/ lib/cellib/cmospw/rb. att 
/usr/ local/cad/uw/ lib/cellib/ cmospw/rb.ca 
/usr/ local /cad/uw/ lib/cellib/cmospw/rb. sym 
/usr/local/cad/uw/lib/cellib/cmospw/s_0,att 
/usr/ local/cad/uw/ Iib/cellib/cmospw/s_0.ca 
/usr / local /cad/uw/ lib/cel lib/ cmospw/ s_0. sym 
/ usr / 1 oca 1 / cad/uw/ lib/cellib/ cmospw/ s_l . att 
/usr/ loca 1 /cad/ uw/ lib/cellib/ cmospw/ s_l . ca 
/usr /local /cad/uw/ lib/cell ib/cmospw/ s_l. sym 
/usr /local /cad/uw/ lib/cel 1 ib/cmospw/ s_10. att 
/usr/ local/cad/uw/ 1 ib/cel lib/ cmospw/ s_10 .ca 
/usr/ local/cad/uw/ 1 ib/cel lib/ cmospw/ s_10 . sym 
/usr/local/cad/uw/lib/cellib/cmospw/s_2.att 
/usr/local/cad/uw/lib/cellib/cmospw/s_2.ca 
/ u s r / 1 oca 1 / cad / uw/ 1 ib / ce 1 1 ib / cmos pw/ s_2 . sym 
/usr/ local /cad/uw/ lib/cel lib/ cmospw/ s_3 .att 
/ usr/ local/cad/uw/ 1 ib/ce 1 1 ib/cmospw/ s_3 . ca 
/usr/ local /cad/uw/ lib/cel lib/ cmospw/ s_3.sym 
/usr /local /cad/uw/ lib/cel lib/ cmospw/ s_4. att 
/usr /local /cad/uw/ lib/cell ib/cmospw/ s_4 .ca 
/usr/ local/cad/uw/ lib/cel lib/ cmospw/ s_4 .sym 
/usr/local/cad/uw/lib/cellib/cmospw/  s__5.att 
/usr/ local/cad/uw/ lib/cel 1 ib/cmospw/ s_5 .ca 
/usr/ local/cad/uw/ lib/cel 1 ib/cmospw/ s_5. sym 
/usr/ local/cad/uw/ lib/cel lib/cmospw/ s_6 . att 
/usr /local /cad/uw/ lib/cel lib/ cmospw/ s_6.ca 
/usr/ local/cad/uw/ 1 ib/ce 1 lib/cmospw/ s_6 . sym 
/usr/ local/cad/uw/ 1 ib/ce 1 lib/ cmospw/ s_7 .att 
/usr/ local /cad/uw/ lib/cell ib/cmospw/ s_7.ca 
/usr/ local/cad/uw/ 1 ib/cel 1 ib/cmospw/ s_7 . sym 
/ usr / local /cad/uw/ 1 ib/ce 1 lib/ cmospw/ s_8. att 
/usr /local /cad/uw/ lib/cel lib/ cmospw/ s_8 .ca 
/usr/local/cad/uw/lib/cellib/cmospw/s_8 .sym 
/usr/local/cad/uw/lib/cellib/cmospw/s_9 .att 
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/usr/ local/ cad/uw/lib/cellib/cmospw/s_9 .ca 
/usr/local/cad/uw/lib/cellib/cmospw/s_9.sym 
/usr/ local /cad/uw/ lib/cel lib/ isocmos 
/ usr / local/ cad/uw/ 1 ib/cel lib/ isocmos/ README 
/usr /local /cad/uw/ lib/cel lib/ isocmos/clkinv.att 
/ usr /local /cad/uw/ 1 ib/cel lib/ isocmos/clkinv.ca 
/usr /local /cad/uw/ lib/cel lib/ isocmos/clkinv.sym 
/usr /local /cad/uw/ lib/cel lib/ isocmos/dlatch.att 
/usr / local /cad/uw/ lib/cel lib/ isocmos /dlatch.ca 
/usr/ local /cad/uw/ lib/cel lib/ isocmos /dlatch . sym 
/usr/local/cad/uw/lib/cellib/isocmos/dlatchr .att 
/ usr / local /cad/uw/ lib/cel lib/ isocmos /dlatchr .ca 
/u3r/local/cad/uw/lib/cellib/isocmos/dlatchr .sym 
/usr /local /cad/uw/ lib/cel lib/ isocmos /dp. att 
/usr / local /cad/uw/ 1 ib/cel lib/ isocmos /dp. ca 
/usr/ local /cad/uw/ lib/cel lib/ isocmos /dp. sym 
/usr/ local /cad/uw/ lib/cel lib/ isocmos/ frame40 .att 
/usr/local/cad/uw/lib/cellib/isocmos/frame40.ca 
/usr/local/cad/uw/lib/cellib/isocmos/frame40.sym 
/usr/local/cad/uw/lib/cellib/isocmos/gb.att 
/usr /local /cad/uw/ lib/cel lib/ isocmos/gb.ca 
/usr/local/cad/uw/lib/cellib/isocmos/gb.sym 
/usr /local /cad/uw/ lib/cel lib/ isocmos/gnd. att 
/usr/local/cad/uw/lib/cellib/isocmos/gnd.ca 
/usr/local/cad/uw/lib/cellib/isocmos/gnd.sym 
/usr/ loca 1 / cad/uw/ 1 ib/ cell ib/ isocmos / inpad . att 
/usr /local /cad/uw/ lib/cel lib/ isocmos/ inpad. ca 
/usr/ local /cad/uw/ lib/cel lib/ isocmos/ inpad. sym 
/usr/local/cad/uw/lib/cellib/isocmos/inv.att 
/usr /local /cad/uw/ lib/cel lib/ isocmos/ inv.ca 
/usr/ local /cad/uw/ lib/cel lib/ isocmos/ inv. sym 
/usr/ local /cad/uw/ lib/cel lib/ isocmos /makefile 
/usr/local/cad/uw/lib/cellib/isocmos/md.att 
/usr /local /cad/uw/ lib/cel lib/ isocmos/md.ca 
/usr/ local /cad/uw/ lib/cel lib/ isocmos/md . sym 
/usr/local/cad/uw/lib/cellib/isocmos/mp.att 
/usr/ local /cad/uw/ 1 ib/cel lib/ isocmos /mp .ca 
/usr/local/cad/uw/lib/cellib/isocmos/mp.sym 
/usr /local /cad/uw/ lib/cel lib/ isocmos/nand2 .att 
/usr/ local /cad/uw/ lib/ cel lib/ isocmos /nand2 . ca 
/usr/ local/cad/uw/ lib/cel lib/ isocmos /nand2 . sym 
/usr/local/cad/uw/lib/cellib/isocmos/nand3.att 
/usr /local /cad/uw/ lib/cel lib/ isocmos/nand3.ca 
/usr / loca 1 /cad/uw/ 1 ib/cel lib/ isocmos /nand3 .sym 
/usr / loca 1 /cad/uw/ lib/cel lib/ isocmos/ nand4. att 
/ usr / local /cad/uw/ 1 ib/cel lib/ isocmos/nand4.ca 
/usr/local/cad/uw/lib/cellib/isocmos/nand4.sym 
/usr/ 1 ocal /cad/uw/ 1 ib/cel lib/ isocmos /nor 2 .att 
/usr /local /cad/uw/ lib/cel lib/ isocmos /nor 2 .ca 
/usr/ local/cad/uw/ 1 ib/cel lib/ isocmos /nor 2 . sym 
/usr/ local/cad/uw/ 1 ib/cel lib/ isocmos /nor 3 .att 
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/usr/local/cad/uw/lib/cellib/isocmos/nor3 .ca 

/usr/ local /cad/uw/ lib/cellib/isocmos/nor3 .sym 

/usr/ local/cad/uw/ lib/cel lib/ isocmos/nor4 .att 

/usr/ local/cad/uw/ lib/cel lib/ isocmos/nor4 .ca 

/usr/local/cad/uw/lib/cellib/isocmos/nor4.sym 

/usr/ local/cad/uw/ 1 ib/cel lib/ isocmos/on . att 

/usr/local/cad/uw/lib/cellib/isocmos/on.ca 

/usr/ local/cad/uw/ 1 ib/cel lib/ isocmos/on. sym 

/usr/local/cad/uw/lib/cellib/isocmos/op.att 

/usr/local/cad/uw/lib/cellib/isocmos/op.ca 

/usr/local/cad/uw/lib/cellib/isocmos/op.sym 

/usr/local/cad/uw/lib/cellib/isocmos/outpad.att 

/usr /local /cad/uw/ 1 ib/cel lib/isocmos/outpad.ca 

/ usr /local /cad/uw/ 1 ib/cel lib/ isocmos/outpad. sym 

/usr/ local /cad/uw/ lib/ cel lib/isocmos/pvs .att 

/usr/ local/cad/uw/ lib/cellib/isocmos/pvs .ca 

/usr/ local/cad/uw/ lib/cel lib/ isocmos/pvs . sym 

/usr/local/cad/uw/lib/cellib/isocmos/rb.att 

/usr /local /cad/uw/ lib/cel lib/isocmos/rb.ca 

/usr/local/cad/uw/lib/cellib/isocmos/rb.sym 

/usr / local /cad/uw/ lib/cel lib/ isocmos/sel2inv. att 

/usr / local/ cad/uw/ lib/cellib/isocmos/sel2inv.ca 

/usr/local/cad/uw/lib/cellib/isocmos/sel2inv.sym 

/usr/local/cad/uw/lib/cellib/isocmos/svd.att 

/usr/ local/cad/uw/ 1 ib/cel 1 ib/isocmos/ svd .ca 

/usr/ loca 1 / cad/ uw/ 1 ib/ ce 1 1 ib/ isocmos / svd . sym 

/usr / local /cad/uw/ lib/cel lib/ isocmos/ tripad. att 

/usr/local/cad/uw/lib/cellib/isocmos/tripad.ca 

/usr /local /cad/uw/ lib/cel lib/ isocmos/ tripad. sym 

/usr/ local/cad/uw/ lib/cel lib/isocmos/ tripadm.att 

/usr / local/cad/uw/ lib/cel lib/ isocmos/ tripadm.ca 

/usr/ loca 1 / cad/uw/ 1 ib/ ce 1 1 ib/isocmos / tr ipadm . sym 

/usr/ local/cad/uw/ lib/cel lib/isocmos/ vdd . att 

/usr/ local/cad/uw/ lib/cel lib/isocmos/vdd.ca 

/usr/ local/cad/uw/ 1 ib/cel lib/ isocmos /vdd. sym 

/usr/local/cad/uw/lib/cellib/isocmos/xor2 .att 

/usr/ local/cad/uw/ lib/cellib/isocmos/xor2.ca 

/usr/ local /cad/uw/ 1 ib/cel lib/ isocmos/xor2 .sym 

/usr / local /cad/uw/ lib/ rnl/plot. 1 

/usr/ local/cad/uw/ lib/rnl/uwsim. 1 

/usr / local /cad/uw/ lib/rnl/uwstd. 1 

/usr /local /cad/ lib/bane/libc. lib 

/usr /local /cad/ lib/bane/ inv. cl 1 

/usr/ loca 1 /cad/ lib/bane/ libacc . a 

/usr/local/cad/lib/bane/liblocal.a 

/usr/ local /cad/ lib/bane/ stipples .c 

/usr/ local /cad/ lib/bane/ stipples .h 

/usr/local/cad/lib/bane/c_ext .ell 

/usr/ local /cad/ lib/bane/ stipples .x 

/usr/ local /cad/ lib/ bane/ aedcolors .h 

/usr/ loca 1 /cad/ lib/bane/cl lmap.cmos 


nsi 
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/ us r/ local /cad/ 1 ib/ bane/ cl lmap.nmos 
/usr/ local/cad/ lib/bane/cllmap.pmos 
/usr/ local/cad/ 1 ib/ bane/ s_ext .cl  1 
/usr /local /cad/ lib/bane/ libs.cif 
/usr/ local/cad/ lib/ bane/ cif map. cmos 
/usr/ local/cad/ lib/ bane/ cif map.  mros 
/usr/ local/cad/ lib/bane/cif map. dmos 
/usr/ local/cad/ lib/bane/cifmap.pmos 
/usr/ local/cad/ lib/ bane /font .h 
/usr/ local/cad/ 1 ib/bane/ font .GouldB 
/usr/ local/cad/ 1 ib/bane/ libs .lib 
/usr/ local/cad/ 1 ib/bane/ READ_ME 
/ usr/ local /cad/ lib/c lay/ cif lib/ H_bothdiff 
/usr/ local/cad/ lib/clay/cif lib/V_bothdiff 
/usr/ local/cad/ lib/c lay /cif lib/bottomdiff 
/usr/ local /cad /lib/c lay/ cif lib/dif f 
/usr/ local/cad/ lib/clay/cif lib/ dpcontact 
/usr/ local/cad/ lib/clay/cif lib/dpcontacthd 
/usr/ local/cad/ lib/clay/cif lib/dpcontactvd 
/usr/ local/cad/ lib/clay/cif lib/ lef tdif f 
/usr/ local/cad/ lib/clay/cif lib/ mdcontact 
/usr/ local/cad/lib/clay/cif lib/metal 
/usr /local /cad /lib/ clay /cif lib/mpcontact 
/usr/ local/cad/ lib/clay/cif lib/ poly 
/usr/ local /cad/ lib/clay/cif lib/ pulldown 
/usr/ local /cad/ lib/clay/cif lib/pul ldownr 
/usr /local /cad/ lib/clay/cif lib/pullup 
/ usr /local /cad/ lib/clay/cif lib/pul lupvg 
/usr/ local/cad/ lib/clay/cif lib/ rightdiff 
/usr/ local/cad/ lib/clay/cif lib/ topdiff 
/usr /local /cad/ lib/ earl /CMOS. head 
/usr/ local /cad/ lib/ earl /CMOS. head .cif 
/usr/ local/cad/ lib/ earl /NMOS. head 
/ usr / loca 1 /cad/ lib/ earl /NMOS. head .old 
/usr/ local/cad/ lib/ earl /clap 
/usr/ local/cad/ lib/ earl /cmos 
/ usr / loca 1 /cad/ lib/ earl/ cpads .e 
/usr/ local/cad/ lib/earl/nmos 
/usr/ local/cad/ lib/ earl/ npadexamp.e 
/usr/ loca 1 /cad/ lib/ ear 1 / npads ,e 
/usr/ local/cad/ lib/ ear  1 /old 
/usr/ local/cad/ 1 ib/earl/outpad .cif 
/usr /local /cad/ lib/ earl /pat terns 
/usr/ local/cad/ li b/ earl /river  .e 
/usr/ local/cad/ lib/ earl/ sospads .e 
/usr/ local/cad/ 1 ib/earl/ test .head 
/usr/ local/cad/ lib/ear  1/ tripad .cif 

/usr/ local /cad/ Stanford/ src/ PI PELINE83/SRC/CIF/TEST/CMOS 

/pmostest .cif 

/usr /local /cad/ Stanford/ src/ PI PELINE83/ SRC/C IF/TEST/CMOS 

/RESULTS/ pmostest .co 
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DRAWER:  Libraries 

UNIX  DIRECTORY:  perm_libs 

-  TOOL  LIST  -  {Contd.) 

/usr/ local /cad/ Stanford/ src/PIPELINE83/SRC/CIF/TEST/CMOS 

/ RESULTS /cmos test .co 
/usr/ local /cad/ Stanford/ src/ PI PELINE8 3/ SRC/CIF/ TEST/CMOS 

/cmostest .cif 

/usr/ local /cad/ Stanford/ src/ PIPELINE83/SRC/CIF/TEST/NMOS 

/RESULTS/nmostest .co 
/usr/ local /cad/ Stanford/ src/ PI PELINE8 3 /SRC/CIF/TEST/NMOS 

/nmostest .cif 

/usr/ local /cad/ stanf ord/src/PIPELINE83/ SRC/CIF/cif 
/usr/ local /cad/ Stanford/ src/ PI PELINE8 3/ SRC/CIFLOAD/ TEST 

/NMOS/RESULTS/nmostest .cif 

/usr/ local /cad/ Stanford/ src/ PI PELINE8 3/ SRC/CIFLOAD/ TEST 

/NMOS/nmostest ,ci 

/usr/ local /cad/ Stanford/ src/PIPELINE83/SRC/CIFLO AD/TEST 

/CMOS/RESULTS/cmostest .cif 

/usr/ local/cad/stanford/src/PIPELINE83/SRC/CIFLOAD/TEST 

/CMOS/cmostest .ci 

/usr/ local /cad/ Stanford/ src/ PI PELINE8 3 /SRC/CLL2/cllmap. cmos 
/usr/ local /cad/ stanford/src/PIPELINE83/SRC/APLOT/TEST 

/nmostest .co 

/usr/local/cad/stanford/src/PIPELINE83/SRC/RPLOT/TEST 

/cmostest .co 

/usr/local/cad/stanford/src/PIPELINE83/SRC/RPLOT/cmos_ts.cll 

/usr/ local /cad/ stanf ord/src/PIPELINE83/SRC/RPLOT/rrplot. bin 

/ usr/ local /cad/ stanford/src/PIPELINE83/SRC/RPLOT/ cmostest .co 

/usr /local /cad/ Stanford/ src/ PIPELINE83/ SRC/ RPLOT/old_rplt .bin 

/ usr /local /cad/ Stanford/ src/ PIPELINE83/ SRC/ RPLOT/ rrplot.bin. deb 

/ usr / loca 1 /cad/ Stanford/ src/ PLAGEN/PLA/ TEST/ test. pla 

/usr/ 1 oca 1/ cad/ Stanford/ src/ PLAGEN/ PLAGUE/ TEST/ test .pig 

/usr/ local/cad/stanford/ src/PLAGEN/PLAGUE/TEST/RESULTS/ test .pla 

/usr/ local/cad/stanford/src/aedcolors .h 

/usr/ local/cad/stanford/src/stipples .x 

/usr/ local /cad/ stanf ord/celllib83 

/usr/ loca 1 /cad /Stanford/ cel 1 lib83/ libs .cif 

/usr/local/cad/stanford/lib/libacc.a 

/usr/ local/cad/stanford/ lib/ liblocal .a 


DRAWER:  Statistics 

UNIX  DIRECTORY:  perm_stats 

-  TOOL  LIST  - 


DRAWER:  Schedules 

UNIX  DIRECTORY:  perm_sched 

-  TOOL  LIST  - 


DRAWER:  Design  Data 

UNIX  DIRECTORY:  perm_data 
-  TOOL  LIST  - 
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DRAWER:  Source  Code 

UNIX  DIRECTORY:  perm_sources 

-  TOOL  LIST  - 

/usr/ local/cad/stanford/src/DRC83/Makef ile.bac 

/usr/ local/cad/stanford/src/PIPELINE83/SRC/ Cl P/ Makefile 

/usr/ local /cad/ Stanford/ src/ PI PELINE8 3 /SRC/CIF/ Protomake. bak 

/usr/ loca 1 /cad/ s tanford/ src/ PI PELINE8 3 /SRC/CIF/ Makefile. bak 

/usr / loca 1 /cad/ Stanford/ src/ P I PELINE8 3/ SRC/CIF/ Protomake 

/usr/ loca 1/ cad/ Stanford/ src/ PIPELINES 3 /SRC/CIFLOAD/ Makefile 

/usr/ loca 1 /cad/ Stanford/ src/PIPELINE83/SRC/CIFLOAD/Protomake 

/usr/ loca 1 / cad/ s tanford/ src/ PI PELINE83/ SRC/ CLL2/ Makefile 

/usr/ loca 1/ cad/ Stanford/ src/ PI PELINE8 3/ SRC/ CLL2/ Protomake 

/usr/ loca 1/cad/ Stanford/ src/PIPELINE83/ SRC/ APLOT/Makefile 

/usr /local /cad/ Stanford/ src/ PI PELINE8 3/ SRC/ APLOT/ Protomake 

/usr/ loca 1/cad/ Stanford/ src/ PI PELINE8 3/ SRC/ RPLOT/ Protomake 

/usr/local/cad/stanford/src/PIPELINE83/SRC/RPLOT/ Makefile 

/usr/ loca 1/cad/ Stanford/ src/ PLAGEN/PLA/Makef ile 

/ usr / loca 1 /cad/ Stanford/ src/ PLAGEN/ PLAGUE/ Makefile 

/usr/ local /cad/ stanford/lib/Makef ile 

/usr/ local/ cad/ Stanford/ lib/tmake 

/usr/ local/cad/stanford/ lib/Makef ile .bak 

/usr/ local/cad/bin/nmake 

/usr/ loca 1/cad/ bin/ makesm 

/usr/ loca 1/cad/ include 

/ usr /loca 1/cad/ include/ plap 

/usr/ local/ cad/ include/plap/gconst.h 

/usr/local/cad/include/plap/gtype.h 

/ usr/ loca 1 / cad/ include/plap/gvar.h 

/usr/ local/cad/ include/plap/macros .h 

/ usr / loca 1/ cad/ include/ plap/ primitive. h 

/usr /loca 1/cad/ include/ plap/ prog. h 

/usr /loca 1/cad/ include/ plap/ nodes .h 

/ usr /loca 1/cad /include/ plap/ error .i 

/usr/local/cad/include/plap/error .h 

/usr/local/cad/uw/include 

/usr/local/cad/uw/include/sys 

/ usr/ local /cad/ uw/include/sys/om_consts.h 

/ usr / local /cad/ uw/include/sys/om_dmacros.h 

/usr /local /cad/uw/include/sys/om_omacros .h 

/usr/ local /cad/ uw/include/plap3 

/usr/ loca l/cad/uw/include/plap3/gconst.h 

/usr/ local /cad/uw/ include/plap3/gtype .h 

/usr/ loca 1 /cad/uw/ inc lude/ p lap3 / gvar .h 

/ usr/ loca 1 /cad/ uw/ inc lude/pl ap3/ user .h 

/usr/local/cad/uw/include/plap3/setup.h 

/usr/ loca 1 /cad/uw/ inc lude/ pi ap3/ at tr ibute .h 

/usr/ loca 1 /cad/ uw/ inc lude/ plap3/bb locks .h 

/usr/ loca 1 /cad/uw/ inc lude/ p 1 ap3 / pr imi t ive .h 

/ usr/ local /cad/uw/ inc lude/ pi ap3/ macros .h 

/usr/ local /cad/uw/ inc lude/ pi ap3/ nodes .h 

/usr/ loca 1 /cad/uw/ inc lude/plap3/ error .h 

/usr/ local /cad/uw/ inc lude/ plap3/nmos.h 

/usr/ local /cad/uw/ include/plap3/isocmos .h 

/usr/ local /cad/uw/ inc lude/ pi ap3/ i21 .h 


DRAWER:  Source  Code 

UNIX  DIRECTORY:  perm  sources 

-  TOOL  LIST  -  (ContdT) 

/usr/ local/cad/uw/include/plap3/i21type .h 
/usr/ local /cad/ uw/ include/ plap3/cmospw.h 
/usr/ local /cad/uw/include/plap3/i21ext.h 
/usr/local/cad/uw/include/plap3/nmosext.h 
/usr/ local /cad/ uw/include/plap3/isocmosext.h 
/usr/ local /cad/uw/include/plap3/cmospwext .h 
/usr / local/cad/uw/ include/ plap3/isocells.h 
/usr/ local/cad/uw/ include/plap3/isopads .h 
/usr/ local/cad/ lib/clay/PLA.c 
/usr/local/cad/lib/clay/PLA_funcs .h 
/usr/local/cad/lib/clay/README 
/usr/local/cad/lib/clay/ext_def .h 
/usr / local /cad/ lib/ clay/ logic. c 
/usr/local/cad/lib/clay/header .h 
/usr/local/cad/lib/clay/new_def .h 
/usr/ local/cad/ lib/clay/river .c 
/usr /local /cad/ lib/c lay/ clayread.h 
/usr/ local/cad/ lib/clay/ trans .c 
/usr/ local/cad/ lib/ clay /claywrite .h 
/usr/local/cad/lib/clay/scn.h 
/usr/ loca 1 /cad / 1 ib/c lay/ system_NMOS . h 
/usr/ loca 1 / cad/ lib/clay/ sy s  temheader . h 
/usr/ local/cad/ lib/clay/ trace. h 
/usr/local/cad/lib/clay/user_NMOS.h 
/ us r / 1 oca 1 / cad / 1 ib/ c 1 ay / user header . h 
/usr/local/cad/stanford/src/DRC83/bool .c 
/usr/local/cad/stanford/src/DRC83/boolf .c 
/usr/local/cad/stanford/src/DRC83/bsort .c 
/usr /local /cad/ stanford/src/DRC83/btopen.c 
/usr /local /cad/ stanford/src/DRC83/butcondrop.c 
/usr/ loca 1 / cad/ Stanford/ src/ DRC8  3/butconexp . c 
/usr/local/cad/stanford/src/DRC83/cmosextr.c 
/usr /local /cad/ Stanford/ src/DRC8 3 /conv.c 
/ usr / loca 1 / cad/ Stanford/ src/ DRC  83/ cover . c 
/usr /local /cad/ Stanford/ src/ DRC8 3 /csort.c 
/usr/local/cad/stanford/src/DRC83/diodechk.c 
/usr/local/cad/stanford/src/DRC83/errout.c 
/usr/local/cad/stanford/src/DRC83/exp.c 
/usr/local/cad/stanford/src/DRC83/expand.c 
/usr/local/cad/stanford/src/DRC83/frontsort.c 
/usr/local/cad/stanford/src/DRC83/fullexp.c 
/usr/local/cad/stanford/src/DRC83/impchk.c 
/usr /local /cad/ Stanford/ src/ DRC8 3/ inter sect .c 
/ usr/ local /cad/ Stanford/ src/ DRC8 3 /isect_exc.c 
/usr /local /cad/ Stanford/ src/ DRC8 3/mask. c 
/  usr /local /cad/ Stanford/ src/ DRC8 3 /nmosextr.c 
/usr /local /cad/ Stanford/ src/ DRC83/orcmos.c 
/  usr/ local /cad/ Stanford/ src/ DRC8 3/ ornmos.c 
/usr /local /cad/ Stanford/ src/ DRC8 3 /pnbuttcon.c 
/usr/ loca 1/cad/ Stanford/ src/DRC83/pplusdiff.c 
/usr/local/cad/stanford/src/DRC83/pwellchk.c 


DRAWER:  Source  Code 

UNIX  DIRECTORY:  perm_sources 

-  TOOL  LIST  -  (Contd.) 

/usr/local/cad/stanford/src/DRC83/rectexp.c 

/ usr / loca 1 / cad/ s  tanf ord/ src / DRC83 / rmbu tcon . c 

/usr/local/cad/stanford/src/DRC83/sep.c 

/usr/local/cad/stanford/src/DRC83/separate.c 

/usr/local/cad/stanford/src/DRC83/sepchk.c 

/usr/local/cad/stanford/src/DRC83/sepdpbur .c 

/usr/ local /cad/ Stanford/ src/ DRC8 3/ sepdpch.c 

/usr/ loca 1 / cad/ Stanford/ src / DRC8  3 / sepone . c 

/usr/ local /cad/ Stanford /src/ DRC8 3 /shrink. c 

/ usr/ loca 1 / cad/ s tanf ord/ src/ DRC8  3 / tranbur ied . c 

/usr/ local /cad/ Stanford/ src/DRC83/trandiff.c 

/usr /local /cad/ Stanford/ src/DRC8 3/ tranexp.c 

/usr/local/cad/stanford/src/DRC83/trdiff .c 

/usr/ local/cad/stanford/src/DRC83/ trpol .c 

/usr /local /cad/ Stanford/ src/ DRC8 3 /twocover.c 

/usr/ local/cad/stanford/src/DRC83/ twoint_exc.c 

/usr /local /cad/ Stanford/ src/ PIPELINE8 3/ SRC/CLL2/add_depend.c 

/usr /local /cad/ Stanford/ src/ PIPELINE83/ SRC/CLL2/C 11 2. c 

/usr/ loca 1 /cad/ Stanford/ src/ PIPELINE8  3 / SRC/CLL2 / c 1 1 2 . h 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CLL2/cll2b.c 

/usr /local /cad/ stanf ord/ src/PIPELINE83/SRC/CLL2/cll2gram.c 

/usr/ local/cad/ Stanford/ src/ PIPELINE83/SRC/CLL2/cll2gram.h 

/usr /local /cad/ stanf ord/ src/ PIPELINE83/SRC/CLL2/cll2gram.y 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CLL2/cll_opt.c 

/ usr/ loca 1 / cad/ stanf ord/ src/ PIPELINE8 3 / SRC/ CLL2/ cs tar tact . c 

/usr/ local /cad/ stanf ord/ src/PIPELINE83/SRC/CLL2/dimension.c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CLL2/intfunc.c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CLL2/raatrix.c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CLL2/newcll.c 

/usr /local /cad/ stanf ord/ src/PIPELINE83/SRC/CLL2/pwidth.c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CLL2/s_ext.cll 

/usr /local /cad/ stanf  ord/ src/ PIPELINE83/SRC/CLL2/set__ext.c 

/usr / local/cad/ stanf ord/ src/PIPELINE83/SRC/CLL2/set_pass.c 

/usr /local /cad/ stanf ord/ src/ PIPELINE83/SRC/CLL2/switchtab.c 

/usr / local/cad/ stanf ord/ src/ PIPELINE83/SRC/CLL2/yymain.c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CLL2/cllmap.nmos 

/usr/ local/cad/ stanf ord/ src/PIPELINE83/SRC/CLL2/cllmap.pmos 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CLL2/ncll2.c 

/usr /local /cad/ stanf ord/ src/PIPELINE8 3/ SRC/CLL2/nnew.c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CLL2/Protomake.bak 

/usr /local/cad/ stanf ord/ src/ PIPELINE83/SRC/CLL2/errorf ile 

/usr /local /cad/ stanf ord/ src/ PIPELINE83/ SRC/ CLL2/Makefile.bak 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CLL2/acll2.c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CLL2/aadd_depend.c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CLL2/acll2 .h 

/usr /local /cad/ stanf ord/ src/ PI PELINE83/SRC/CLL2/ac 11 2b. c 

/usr /local /cad/ stanf ord/ src/ PI PELINE83/SRC/CLL2/acll2gram.c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CLL2/acll2gram.h 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CLL2/acll2gram.y 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CLL2/acll_opt.c 

/usr/ local /cad /stanf ord/ src/PIPELINE83/SRC/CLL2/acstartact.c 


DRAWER:  Source  Code 

UNIX  DIRECTORY:  perm_sources 

-  TOOL  LIST  -  (Contd.) 

/usr/ local/cad/stanford/src/PIPELINE83/SRC/CLL2/adimension.c 

/usr/ local /cad/ Stanford/ src/ PI PELINE83/SRC/CLL2/aintfunc.c 

/usr/ loca 1 /cad/ Stanford/ src/ PI PELINE8 3/ SRC/CLL2/amatrix.c 

/usr/ local/cad/stanford/src/PIPELINE83/SRC/CLL2/anewcll .c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CLL2/cll2  h.bak 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CLL2/apwi<Jth.c 

/usr /local /cad/ Stanford/ src/ PI PELINE8 3/ SRC/CLL2/aset_ext.c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CLL2/aset_pass.c 

/usr /local /cad/ Stanford/ src/ PIPELINE8 3/ SRC/ CLL2/ayymain.c 

/ usr /local /cad/ Stanford/ src/ PIPELINE8 3/ SRC/ BANE/concat.c 

/usr /local /cad/ Stanford/ src/ PI PELINE8 3/ SRC/ BANE/err2co.c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/BANE/bane.l 

/usr/ local /cad/ Stanford/ src/ PIPELINE8 3/ SRC/ BANE/ lock.c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/BANE/mktemp.c 

/usr/ local /cad/ Stanford/ src/ PI PELINE8 3/ SRC/BANE/window.c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/BANE/xy2co.c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/BANE/err2co. 1 

/usr/local/cad/stanford/src/PIPELINE83/SRC/BANE/spathnames.h 

/usr/ local /cad/ Stanford/ src/PIPELINE83/ SRC/ BANE/Makef ile 

/usr/ local/cad/ Stanford/ src/ PIPELINE83/ SRC/ BANE/ Protomake 

/usr/local/cad/stanford/src/PIPELINE83/SRC/BANE/bane.c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/BANE/err2co.l 

/usr /local /cad/ stanford/src/PIPELINE83/SRC/BANE/xy2co.l 

/usr/ local/cad/ Stanford/ src/PIPELINE83/SRC/BANE/READ_ME 

/usr/local/cad/stanford/src/PIPELINE83/SRC/BANE/lex.yy.c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/BANE/ spathnames.hba 

/usr/local/cad/stanford/src/PIPELINE83/SRC/APLOT/aplot.c 

/usr /local /cad/ stanford/src/PIPELINE83/SRC/APLOT/plot.c 

/usr / local/cad/ Stanford/ src/ PIPELINE83 /SRC/ APLOT/plot.h 

/usr/ local/cad/ Stanford/ src/PIPELINE83/SRC/RPLOT/backupconcat.c 

/usr /local /cad/stanford/src/PIPELINE83/SRC/RPLOT/blockout.c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/RPLOT/convert.c 

/usr /local /cad/ Stanford/ src/ PIPELINE83/SRC/RPLOT/merge.c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/RPLOT/ rrplot.c 

/usr /local /cad/ Stanford/ src/ PI PELINE8 3/ SRC/ RPLOT/r sort. c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/RPLOT/ tplot .c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/RPLOT/unconvert.c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/RPLOT/window.c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/RPLOT/font.GouldB 

/ usr /local /cad/ Stanford/ src/ PIPELINE8 3/ SRC/ RPLOT/font.h 

/usr/local/cad/stanford/src/PLAGEN/PLA/pla.c 

/usr /local /cad/ Stanford/ src/ PLAGEN/PLA/ parse. h 

/usr/local/cad/stanford/src/PLAGEN/PLA/pla.h 

/usr/ local/cad/stanford/lib/cifout-io.c 

/usr /local /cad/ stanford/lib/ckopen.c 

/  usr /local /cad/ stanford/lib/cwd.c 

/usr/local/cad/stanford/lib/data.c 

/  usr/ local /cad/ stanford/lib/dir.h 

/usr/ local/cad/stanford/lib/f indargs .c 

/ usr / loca 1 /cad/ Stanford/ lib/ flsbuf .c 

/usr/ loca 1 /cad/ s  tanf ord/ 1 ib/ge taed . c 
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DRAWER:  Source  Code 

UNIX  DIRECTORY:  perm_sources 

-  TOOL  LIST  -  (Contd.) 

/usr/ local /cad/ stanford/lib/malloc.c 

/usr/ loca 1/cad/ Stanford/ lib/ pa thtail .c 

/usr/local/cad/stanford/lib/pen_plot.c 

/usr /local/ cad/ stanford/lib/permalloc.c 

/usr/local/cad/stanford/lib/scale.c 

/usr /loca 1/cad/ Stanford/ lib/ scanswitch.c 

/usr/local/cad/stanford/lib/setext.c 

/usr/ loca 1/cad/ Stanford/ lib/ stipples. c 

/usr/ loca 1/cad/ Stanford/ lib/ stipples .h 

/usr/ loca 1 /cad/ Stanford/ 1 ib/ swtab . h 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CIF/cif .c 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CIF/user_act.c 

/usr /local /cad/ stanford/src/PIPELINE83/SRC/CIF/yymain.c 

/usr/ loca 1/cad/ Stanford/ src/PIPELINE83/SRC/CIF/cif .h 

/usr/local/cad/stanford/src/PIPELINE83/SRC/CIF/cifgram.y 

/usr /loca 1/cad/ Stanford/ src/PIPELINE83/SRC/CIF/ scanswitch.c 

/usr /local /cad/ Stanford/ src/PIPELINE8 3/ SRC/CIF/cif gram. h 

/usr/ local/cad/ Stanford/ src/PIPELINE83/SRC/CIF/cif gram. c 

/usr /local /cad/ Stanford/ src/PIPELINE83/SRC/CIFLOAD/cifar.c 

/usr /local /cad/ stanford/src/PIPELINE83/SRC/CIFLOAD/cif load.c 

/usr /local /cad/ stanford/src/PIPELINE83/SRC/CIFLOAD/scif loader .c 

/usr /local /cad/ stanford/src/PIPELINE83/SRC/CIFLOAD/splitfile.c 

/usr/ local/cad/ stanford/src/PIPELINE83/SRC/CIFLOAD/cif load.h 

/usr/ local/cad/ stanford/src/PLAGEN/PLA/ parse. y 

/usr/local/cad/bin/rrplot.c 


DRAWER:  Aux  Data 

UNIX  DIRECTORY:  perm_aux_data 

-  TOOL  LIST  - 

/usr/ local /cad/uw/ lib 
/usr/local/cad/uw/lib/libdb.a 
/usr/ local /cad/uw/ lib/ 1 ibzgp . a 
/usr/ local /cad/uw/ lib/ 1 ibom . a 
/usr/ local/cad/uw/ lib/ libplap3 .a 
/usr /local/ cad/uw/ lib/ libplnmos . a 
/usr / local /cad/uw/ lib/libpli21. a 
/usr / local /cad/uw/ lib/libplisocmos. a 
/usr /local /cad/uw/ lib/libplcmospw. a 
/usr/ local/cad/uw/ lib/ libpl isocell .a 
/usr/ local /cad/uw/ lib/libpl isopad. a 
/usr/local/cad/uw/lib/psh 
/usr/ local/cad/uw/ lib/psh/cel Is .psh 
/usr/ local/cad/uw/ lib/psh/cmospw. psh 
/usr/ local/ cad/uw/ lib/psh/i21 .psh 
/ usr/ local/cad/uw/ lib/ psh/ isocmos . psh 
/usr /local/ cad/ uw/ lib/psh/nmos .psh 
/usr /local /cad/uw/ lib/ psh/ pads. psh 
/usr/ local/cad/uw/ lib/technology 
/usr/local/cad/uw/lib/technology/nmos.tec 


DRAWER:  Aux  Data 

UNIX  DIRECTORY:  perm_aux_data 

-  TOOL  LIST  -  (Contd.) 

/ usr / loca 1 / cad/ uw/ lib/ techno logy / nmos . cmp 
/usr/ local /cad/uw/lib/technology/nmos. tec2 
/ usr / local/ cad/ uw/ lib/ techno logy/cmospw. tec 
/usr/ loca 1 / cad / uw/ lib/ technology/ cmospw . cmp 
/usr/ loca 1 / cad/ uw/ 1 ib/ techno logy / cmospw . tec  2 
/usr/ local / cad/uw/ lib/ technology/ i2 1 . tec 
/ usr / 1 oca 1 / cad/uw/ lib/ techno 1 ogy / isocmos . tec 
/ u s r / 1 oca 1 / cad / uw/ 1 i b / techno 1 ogy / i s oc mo s . cmp 
/ u s r / 1 oca 1 / cad / uw/ 1 i b / t echno 1 ogy / i s oc mo s . t ec 2 
/usr/ local/cad/uw/bin/db2cif 
/usr/local/cad/uw/bin/db7221 
/usr/ local /cad/uw/bin/db75 80 
/usr/ local /cad/ Stanford/ src/DRC83/mask.h 

/usr/ local /cad/ stanford/src/DRC83/TEST/NMOS/Testburied.c 11 

/usr/local/cad/stanford/src/DRC83/TEST/NMOS/Testburied.co 

/usr/local/cad/stanford/src/DRC83/TEST/NMOS/RESULTS 

/usr/local/cad/stanford/src/DRC83/TEST/NMOS/RESULTS/Test.drc 

/ us r / 1 oca 1 / cad / s tanf ord/ s rc / DRC8 3 / TEST / NMOS / RESULTS / Te stburied . dr c 

/usr/local/cad/stanford/src/DRC83/TEST/CMOS/craos.cif 

/usr/local/cad/stanford/src/DRC83/TEST/CMOS/cmos.cll 

/usr/ local /cad/ stanf ord/ src/DRC83/TEST/CMOS/cmos. co 

/usr/local/cad/stanford/src/DRC83/TEST/CMOS/RESULTS/cmos.drc 

/usr/local/cad/stanford/src/PIPELINE83/SRC/BANE/errorfile 

/usr/ local /cad/ bin/ nmos .tec 

/usr/local/cad/bin/nmos.cmp 

/usr/ local/cad/bin/db7221 
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Appendix  C:  Source  Code  for  a  Partially  Implemented 
VLSI  CAD  Toolkit  Custodian 

A  prototype  VLSI  CAD  toolkit  Custodian  has  been 
designed  to  operate  on  the  AFIT  VAX  11/780.  The  custodian 
has  been  implemented  using  two  programs:  1)  A  UNIX  "C- 
Shell"  script  which  contains  the  actual  custodian  code  and 
2)  A  program  written  in  the  "C"  language  designed  to  permit 
the  author  of  the  custodian  "script"  to  specially  condition 
the  "script".  The  special  conditioning  is  required  so  that 
the  toolkit  components  may  be  accessed  only  via  the 
custodian.  Any  attempts  to  read,  write,  or  execute  toolkit 
components  without  use  of  the  custodian  will  be  denied.  The 
programs  are  presented  in  the  two  separate  sections  that 


follow 


M«! 


m  li_  A  "C-Shel  1"  Custodian  The  program  shown  on 
the  following  pages  will  function  as  the  "custodian"  for  the 
AFIT  VLSI  CAD  Toolkit.  This  version  is  a  prototype  in  the 
truest  sense  of  the  word  and  is  provided  to  illustrate  the 
structure  and  power  of  the  toolkit  custodian.  To  improve 
the  program  readability,  the  source  code  is  printed  in 
small  type  so  that  each  statement  may  be  displayed  on  a 
single  line.  Each  line  of  the  source  code  is  numbered  for 
easy  reference.  The  reader  is  cautioned  to  delete  the  line 
numbers  when  transcribing  the  source  to  a  format  suitable 


for  execution. 


CUSTODIAN  SOURCE  CODE 


1  I!  /bin/csh 

2  I  CUSTODIAN  Version  1.0  28  Nov  1984 

3  I  Thoaas  R.  Veraillion,  Capt.  USAf 

4  I  AFIT/ENfi  Hright-Patterson  AFB,  Ohio 

5  I  reset  the  terainal 

6  setenv  TERNCAP  /etc/teracap 

7  tset  »l  /dev/null 

8  I  set  interrupt,  suspend  and  quit  to  be  the  saae  as  interrupt  to  prevent 

9  I  the  user  froa  interrupting  the  custodian 

10  stty  intr  "V  susp  ,A\’  quit  ,A\’ 

11  I 

12  I  interruption  of  the  custodian  is  not  peraitted  yet 

13  onintr  - 

14  i  enable  aetacharacter  filenaae  expansions 

15  unset  noglob 

16  I 

17  alias  cd  cd  I  just  in  case  there  is  a  strange  alias  in  user  environ 

18  I  set  to  ignore  eof  chars 

19  set  ignoreeof 

20  I 

21  clear 

22  echo  ’  AFIT  VLSI  CAD  TOOLKIT  CUSTODIAN  -  Version  1.0  -  22  Septeaber  1984’ 

^  23  echo  ’  ’ 

24  echo  ’  Unlocking  VLSI  CAD  toolkit.  There  are  7  steps  required.' 

25  echo  '  ’ 

26  echo  STEP  -  Reoarks’ 

27  echo  -n  01  -  You  are  :  * 

28  « 

29  I 

30  | - BEGIN  VARIABLE  INITIALIZATION  AREA - 

31  «  PATH  TO  TOP-LEVEL  DIRECTORY  FOR  THE  VLSI  TOOLKIT 

32  set  TOOLKIT  =  /usr/local/cad/trv/vlsi  tool  kit 

33  I 

34  «  FILE  NANES/PATHS 

35  set  teapath  *  $TOOLKIT/info_storage/teap_storage/teap_dataA<$$ 

36  set  data_access  *  $T00LKIT/agt_tools/data_access 

37  set  pera.area  *  $TO0LKIT/info_storage/pera_storage 

38  set  teaplog  *  tteapath'.log* 

39  set  peralog  *  fdata.access/ 'peraanent.log' 

40  set  peradoc  1  tpera_area/pera_doc 

41  set  securlog  *  $T00LKIT/agt.tools/data_security/security.log 

42  set  taolkit.stats  -  tpera.area/pera.stats/usage.stats 

43  set  bakgnd  ok  list  •  (data  access/’ bakgnd. list’ 

44  I 

45  I  set  users  to  contain  a  list  of  the  FILENAHES 

46  •  which  are  of  lists  of  users. 

47  set  users  :  ’cat  (data  access/user  lists’ 

48  « 

49  «  SET  USER  IDENTIFICATION 

50  set  userid  =  ’uhoaai’ 

51  echo  (user id 
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52 

53 

54 

55 

56 

57 

58 

59 

60 
61 
62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 
81 
82 

83 

84 

85 

86 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 
>00 
101 
>02 
>03 

104 

105 


echo  -n  02  -  Opening  Toolkit  Drapers  : 

I 

*  TOOLKIT  HANA6ER  IDENTIFICATION 
set  agrid  =  ’hcarter’ 

set  agrnaae  3  ’Lt.  Col  H.  Carter’ 
set  agraddr  *  ’Bldg.  640,  Rooa  2x»’ 
set  agrphone  =  ’255  -  mi’ 

« 

«  STANDARD  VARIABLES 
set  true  =  l 
set  False  *  0 

set  bell  3  *  ASCII  BELL  character 

set  aain_aenu  =  ’0’ 

set  done_aain  =  (False 

set  done_skill  *  (False 

set  done_aain_aenu  =  (False 

set  access  3  0 

set  skill  3  0 

set  open_tiae  *  'date* 

set  print# il  3  ’  ’ 

set  backgrnd  =  (False 

I  set  the  statistics 

I  the  stat  File  has  tao  entries  per  statistic,  the  First  entry  is 
t  the  stat  descriptor  and  the  second  is  the  stat  value.  The  First 
t  argueent  in  the  stat  File  is  a  descriptor. 

*  the  statistics  variable  structure  is: 

« 

I  stats! 1]  =  "Current_Active_Toolkit_Sessions:‘ 

I  stats!21  3  nuaber  oF  active  sessions 
I  stats!31  3  "Total _Toolkit_Sessions:* 

I  statsMl  3  total  nuaber  oF  sessions 
t  statsISl  3  "Total _Security_Violations|" 

I  stats!61  3  total  nuaber  oF  security  violations 
set  stats  3  'cat  (tool kit_stats  * 

I 

«  TOOLKIT  NANA6EHENT  VARIABLES 

I 

«  DUffllY  VARIABLES 
set  dua_a  3  0 
set  dua_b  3  0 
set  dua_c  3  0 
set  dua.d  3  0 
set  duaay  3  ’  ’ 

* 

set  process  3  ((  I  process  id  oF  this  invocation 

set  tool  select  3  ’  ’ 

set  Flags  3  ’  ’ 

set  infiles  3  ’  ’ 

set  outFiles  3  ’  ’ 

set  redirect  3  ’  ’ 

< 

( - END  VARIABLE  INITIALIZATION  AREA - 

echo  ’DONE.’ 


\ 

•w 

4 


i 

i 

i 

■ 

5 

>' 

I 

I 

J 


«r 


« 


106  i 

107  echo  -n  03  -  Session  ID  :  ’ 

108  set  session_id  =  topen  Jiae[31topen_tiaeC2]tprocess 

109  echo  tsession_id 

110  echo  -n  04  ■  Creating  Session  Log  :  ’ 

111  * 

112  I  open  teaporary  log 

113  echo  ’  ’  »  tteaplog 

114  echo  »  tteaplog 

115  echo  -n  ’SESSION  OPENED  AT  :  ’  »  tteaplog 

116  echo  topen_tiae  »  tteaplog 

117  echo  'Session  ID  :  ’tsession_id  »tteaplog 

118  echo  ’User  ID  :  ’tuserid  »  tteaplog 

119  echo  ’User  Terainal  Type  :  ’ tTERH  »  tteaplog 

120  echo  ’User  Directory  :  ’tcad  »  tteaplog 

121  echo  ’  ’  »  tteaplog 

122  echo  'Opening  status  of  systea  storage  :  ’  »  tteaplog 

123  •  save  systea  status  snapshot 

124  a  tuserid  »  tteaplog 

125  df  »  tteaplog 

126  echo  ’  ’  »  tteaplog 

127  « 

128  « 

129  echo  ’TOOLKIT  STATISTICS:  At  session  opening  >>  tteaplog 

130  Hoop  through  stat  variables  and  save  thea 

131  8  duaa  *  1 

132  ahile  (tdua_a  <*  tlstats) 

133  •  dua_b  =  tdua_a  ♦  1 

134  echo  tstatsltdua_al’  :  ’ tstatsCtdua_bl  »  tteaplog 

135  t  dua  a  *  tdue_a  ♦  2 

136  end  I  ahile  loop 

137  I  done  aith  stat  var  save 

138  echo  ’  ’  »  tteaplog 

139  echo  ’DONE.’ 

140  echo  -n  ’-  05  -  Testing  Your  Directory  :  ’ 

141  « 

142  I  Test  to  see  if  toolkit  can  access  directory  calling  this 

143  I  prograa  if  no  access  is  alloaed  then  error  aessage 

144  « 

145  if  !(  -r  tcad  )  then 

146  set  done_aain  =  ttrue 

147  endif  •  test  if  user  can  read  his  directory 

148  « 

149  if  !(  -a  tcad  )  then 

150  set  done.eain  =  ttrue 

151  endif  I  test  if  user  can  arite  to  his  directory 

152  • 

153  if  Htdone  earn)  then 

154  echo  ’DIRECTORY  ACCESS  VERIFIED.’ 

155  else 

156  echo  ’ACCESS  DENIED  :  No  access  to  CRD.’  »  tteaplog 

157  set  done  aain  =  ttrue 

158  echo  tbefl’INPROPER  DIRECTORY  ACCESS.’ 

159  echo  ’You  aust  have  READ  6  WRITE  peraission  to  Current  Directory.’ 
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echo  -n  *  PRESS  <R£TURN>  TO  RETURN  TO  OPERATING  SYSTEM 
set  duaaay  -  (f<) 

echo  -n  ’  PLEASE  WAIT  ..  DO  NOT  DEPRESS  ADDITIONAL  KEYS.' 
goto  close J:it 
end if  i  CND  test 

« 

« 

if  !(tdone_aainl  then 
I  Establish  User  access  Level 

< 

I  Check  each  user  LIST  identified  in  the  variable  'users* 

( 

echo  -n  06  -  Toolkit  Access  is  :  ’ 

8  access  *  0 
8  dua_a  -  1 

8  dua_b  =  f (users  I  Nuaber  of  user  lists 

uhile  ($dua_a  <=  $dua_b) 

8  dua_c  =  'fgrep  *x  -c  fuser id  $data_access/tuserslfdua_a]' 

4  if  the  user  is  in  this  list  then  give  hia  access  level  of  list 
if  (tdua_c  >=  i)  then 
8  access  =  tduaa 
endif 

8  dua_a  *  tdua.a  ♦  1 
end  t  uhile  loop 

« 

if  ! ((access)  then 

echo  'ACCESS  DENIED.  :  Not  found  in  access  lists.’  »  tteaplog 
echo  ’  ’  »  tsecurlog 

echo  ’ILLEGAL  ACCESS  ATTEMPT  :  ’  »  tsecurlog 

echo  ’  User  :  ’tuserid  »  tsecurlog 

echo  ’  Tiae  :  ’topen.tiae  »  tsecurlog 

echo  ’  Session  Id  :  ’(sessionjd  »  tsecurlog 

echo  ’  ’  »  tsecurlog 

set  done.aain  =  ttrue 

•  security  violation  -  update  stats 

8  statsUl  -  fstatsUI  *  1 

echo  tstats  >!  ttoolkit.stats  I  update  the  stat  file 
echo  -n  tbell 
echo  ibeir DENIED.’ 

echo  ’You  are  not  on  the  access  list.’ 
echo  ’You  aust  have  pre-established  access  peraission  to  use 

echo  ’the  toolkit.  To  obtain  toolkit  access,  you  aust  do  one 

echo  of  the  folloeing:’ 

echo  ’  1:  Send  a  request  via  systea  aail  to  user  :  ’tagrid 

echo  ’  2:  Personally  contact  the  follouing  person:’ 

echo  ’  ’tagrnaae 

echo  ’  ’fagraddr 

echo  ’  ’tagrphone 

echo  ’  ’ 

echo  -n  ’  PRESS  <RETURN>  TO  RETURN  TO  OPERATING  SYSTEM  -->’ 
set  duaaay  =  ($0 

echo  -n  ’  PLEASE  WAIT  ..  DO  NOT  DEPRESS  ADDITIONAL  KEYS.’ 
goto  closejtit 


I  new  session  -  update  stats 
8  stats!21  -  tstatsI21  ♦  1  I  nueber  of  active  users 
8  statsC 4 ]  -  tstatsltl  ♦  1  I  total  nuaber  of  sessions 
echo  tstats  >!  itool kit_stats  I  update  the  stat  file 
echo  ’ 6RANTED,  level  :  ’taccess 

echo  ’Toolkit  access  granted,  level  :  ’taccess  »  tteaplog 
echo  07  -  Toolkit  is  OPEN.  Please  record  your  session  ID' 
echo  ’  for  use  in  the  event  you  oust  refer  to  this  session.’ 

echo  ’  ’ 

echo  -n  (bell’  PRESS  <RETURN>  and  wait  for  aenu.’ 

set  duaay  =  (to 

echo  -n  ’  PLEASE  WAIT  ..  DO  NOT  DEPRESS  ADDITIONAL  KEYS.’ 

endif  taccess  response  aessages 
endif  I  access  test 

«  NON  ALLON  USER  INTERRUPTS  ..  BUT  THEY  JUHP  TO  GRACEFUL  CLOSE 
onintr  close  kit 

« 

t  OBTAIN  SKILL  LEVEL 
set  skill_aenu  =  ’0’ 

while  (  ! (tdoneskill)  U  ! (tdone.aain)  1 
clear 

echo  ’  eeeeee*  SKILL  LEVEL  teeetet’ 

echo  ’  ’ 

echo  ’  1.  FIRST  TINE  User  of  Toolkit.’ 

echo  ’  ’ 

echo  ’  2.  SOMEWHAT  FAMILIAR  with  Toolkit.’ 

echo  ’  ' 

echo  ’  3.  VERY  FAMILIAR  with  Toolkit.’ 

echo  ’  ’ 

echo  ’  4.  EXPERT  User.’ 

echo  ’  ’ 
echo  ’  ’ 

echo  -n  ’  Enter  Your  Choice  and  press  <RETURN>  ->  ’ 

set  skill_aenu  =  (t<) 

« 

echo  -n  tbell'  PLEASE  WAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS, 

switch  (tskill_aenu) 

case  ’1’: 

echo  ’Skill  select  :  level  'tskill.aenu  )>  tteaplog 
set  skill  -  tskill_aenu 
set  done_skill  *  ttrue 
breaksw 

case  ’2”. 

echo  'Skill  select  :  level  'tskill_aenu  »  tteaplog 
set  skill  =  tski 1 I_aenu 
set  done.skill  =  ttrue 
breaksw 

case  ’3’: 

echo  ’Skill  select  :  level  ’tski  1  l_aertu  )>  tteaplog 
set  skill  *  tski 1 1  aenu 
set  done  skill  *  ttrue 


breaks* 


268 

269 

270  case  *4’: 

271  echo  'Skill  select  ‘  level  ’tskill_aenu  »  tteaplog 

272  set  skill  =  tskillaenu 

273  set  done_skill  *  ttrue 

274  breaks* 

275 

276  default: 

227  echo  'Skill  select  :  input  error  ->  ’tskill  eenu  »  tteeplog 

278  clear 

279  echo  '  -  Skill  selection  help  being  provided.’  »  tteeplog 

280  sore  -d  tperadoc/skillhelp 

281  echo  ’  ’ 

292  echo  -n  ’  Press  (RETURN)  to  continue  ->  ’ 

283  set  dueey  =  ($<) 

284  echo  '  ’ 

285  echo  -n  tbell’  PLEASE  WAIT .  DO  NOT  DEPRESS  ADDITIONAL  KEYS.' 

286  breaks* 

287  ends*  I  skill  level 

288  I 

289  end  i  skill  level  *hile  loop 

290  t 


291 

« 

MAIN 

MENU  LOOP 

292 

t 

293 

while  (  Mtdoneaain  eenu)  U  Htdone  aainl  1 

294 

set  aainaenu 

'0' 

295 

clear 

296 

echo  ’ 

tetttttf  RAIN  H  E  N  U  **tf**t* 

297 

echo  ’  ’ 

298 

echo  ’ 

1.  EXIT  and  return  to  Unix.’ 

299 

echo  ’  ’ 

300 

echo  ’ 

2.  EXECUTE  a  toolkit  coaponent.’ 

301 

echo  ’  ’ 

302 

echo  ’ 

3.  DISPLAY  your  directory  contents.' 

303 

echo  ’  ’ 

304 

echo  ’ 

4.  CHAN6E  your  working  directory.’ 

305 

echo  ’  ’ 

306 

echo  ’ 

5.  VIEN  or  PRINT  a  file.’ 

307 

echo  ’  ’ 

308 

echo  ’ 

6.  Get  HELP.’ 

309 

1 

310 

i 

user  access  to  these  eenu  options  depends  upon  access  level 

311 

f 

312 

if  (taccess  >  1)  then 

313 

echo  ’  ’ 

314 

echo  ’ 

7.  Generate  REPORTS  froa  the  toolkit.' 

315 

endif  t  access  level  >  1  options 

316 

317 

if  (taccess  >= 

21  then 

318 

echo  ’  ’ 

319 

echo  ’ 

8.  Execute  a  toolkit  UTILITY  prograa. ’ 

320 

endif  t  access 

>=  2 

321 

if  ((access  >=  3)  then 
echo  ’  ’ 

echo  ’  9.  MODIFY  the  toolkit.’ 

end if  t  access  level  3  option 

echo  ’  ’ 
echo  ’  ’ 

echo  -n  ’  Enter  Your  Choice  and  press  (RETURN)  ->  ’ 

set  aain_aenu  =  (♦<) 

echo  ’  ’ 

echo  -n  (bell’  PLEASE  WAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS.’ 


switch  ($aain_aenu) 
case 

echo  ’(lain  select  :  EXIT  to  Unix.’  »  (teaplog 
set  done.aain  *  (true 
goto  dose_kit 
breaksw 

case  ’2’: 
clear 

echo  ’Nain  select  :  EXECUTE  tool  described  below:  ’  »  (teaplog 

set  cow aand 

set  coaponent 

set  infiles 

set  outfiles 

set  flags 

•  for  highly  skilled  users 
if  ((skill  >*  3)  then 

echo  ’Enter  the  coaplete  coaaand  line  for  the  coaponent 
set  coaponent  *  (10 
I  for  the  leas  experienced  users 
else 

echo  -n  ’Enter  the  naae  of  the  tool  to  execute  ->  ’ 
set  coaponent  »  («) 

echo  -n  ’Enter  the  naaes  of  all  input  files  ->  ’ 
set  infiles  s  (10 

echo  -n  'Enter  the  naae  of  the  output  file  ->  ’ 
set  outfiles  *  (10 
echo  -n  ’Enter  the  coaaand  flags  ->  ’ 
set  flags  *  («> 
endif  I  skill  >=  3 
echo  ’  ’ 

echo  -n  (bell’  PLEASE  WAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS, 

clear 

I  have  coaplete  input  now  in  the  variable  -  coaaand 
set  coaaand  =  '(coaponent  (flags  linfiles  (outfiles* 
echo  (coaaand  »  (teaplog 
I  test  to  see  if  allowed  to  execute  this  coaponent 

•  authorized  lists  aaintained  as  'tools!'  where  the  X 
I  represents  the  user  access  level 


set  dua_a  =  'fgrep  -x  -c  (coaponentlll  (data_access/tools(access 
if  ((dua_a)  then 

echo  ’  -  Execution  Authorized.’  »  (teaplog 
I  noa  see  if  tool  exists 

« 

set  dua_b  =  'find  (TOOLKIT  -naae  (coaponentlll  -print' 
echo  ’  -  Tool  location  is:  ’  »  (teaplog 
echo  ’  -  ’(dua_b  »  (teaplog 
if  (  -e  (dua_b  1  then 
echo  ’  ’ 

echo  -n  ’EXECUTE  in  the  foreground)  or  B(ackground)  ?  ->’ 
set  duaay  *  («) 
echo  ’  ’ 

echo  -n  (bell’  PLEASE  WAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS.’ 


switch  ((duaay) 
case  *F’: 
clear 

set  backgrnd  -  (false 

echo  ’  -  Executing  in  foreground.’  »  (teaplog 

echo  ’Executing  -  ’(coaponentlll 

(coaaand 

echo  ’  -  Execution  completed,  status  =  ’(status  »  (teaplog 
echo  ’Execution  coapleted,  status  =  ’(status 
breaksw  I  foreground 

case  ’8’: 
clear 

set  dua_a  =  'fgrep  -x  -c  (duo_b  (bafcgnd_ok_I i st ' 
if  ((dua_a)  then 

echo  ’  -  Background  Execution  Authorized.’  »  (teaplog 
set  backgrnd  *  (true 

echo  ’  -  Executing  in  background.’  »  (teaplog 

echo  -n  ’Executing  in  background  :  as  Process  Nuaber  ->’ 

(coaaandt  I  execute  the  job 
else 

echo  ’  -  Background  Execution  NOT  Authorized.’  »  (teaplog 
echo  ’  -  EXECUTION  ABORTED.’  »  (teaplog 
echo  (bell ’EXECUTION  ABATED.  -  Background  Execution  NOT  Authorized.’ 
echo  ’  ’ 

echo  -n  ’  Press  (RETURN)  to  continue  ->  ’ 

set  duaay  =  («) 
echo  ’  ’ 

echo  -n  (bell’  PLEASE  WAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS, 

endif  i  see  if  background  execution  is  ok 
breaksw  I  background 

default: 

clear 

echo  ’  -  EXECUTION  ABORTED.  No  User  Selection.’  »  (teaplog 
breaksw  I  background  default 


endsw  I  foreground  or  background 
else  I  tool  cannot  be  executed 
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clear 

echo  'Can  not  execute  -  ’tcoaponentll)  »  tteaplog 
echo  ’Can  not  execute  -  ’tcoaponentll) 
endif  I  -e  dua_b  existence  test 
else  I  user  is  not  authorized  to  execute  this  tool 
clear 

echo  ’  -  Not  an  authorized  execution  -  ’ (component! 11  »  tteaplog 
echo  ’Not  an  authorized  execution  -  ’tcoaponentll] 
endif  I  due.a  execution  test 
echo  ’  ’ 

echo  -n  ’  Press  <RETURN>  to  continue  ->  ’ 

set  dueey  =  (t<) 
echo  ’  ’ 

echo  -n  tbell’  PLEASE  WAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS, 

breakse 

case  ’3’: 

echo  'Main  select  :  DISPLAY  directory.’  »  tteeplog 
clear 

tT00LKIT/design_tools/utilities/dir  -la  !  aore  -d  I  prints  directory 
echo  ’  ’ 

echo  -n  ’  Press  <RETURN>  to  continue  ->  ’ 

set  duaay  =  (t<) 
echo  ’  ’ 

echo  -n  tbell’  PLEASE  WAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS, 

breakse 

case  ’4’: 

•  NOTE  CANNOT  USE  SOME  'WILDCARD”  SUBSTITUTIONS  HERE 
echo  ’Hain  select  :  CHAN6E  directory  to  :  ’  »  tteaplog 
clear 

echo  -n  ’Enter  NEH  directory  naae  ->’ 
set  duaay  -  (t<) 
echo  ’  ’ 

echo  -n  tbell’  PLEASE  NAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS, 

echo  ’  -  ’tduaay  »  tteaplog 
if  (ttduaay  ==  ’O’)  then 
set  duaay  =  'pad' 

endif  I  safety  factor  for  only  a  return 

if  (  tduaay  --  *  )  then 
set  duaay  *  tHOHE 

endif  t  safety  factor  for  only  a  tilde 

if  (tduaay  --  .)  then 
set  duaay  s  ’pad’ 

endif  I  safety  factor  for  only  a  period 

if  !(  -r  tduaay  )  then 
clear 

echo  ’  -  DIRECTORY  CHAN6E  I6N0RED  :  Cannot  change.’  »  tteaplog 
echo  ’  ’ 

echo  tbell’CHAN6E  IGNORED.  Cannot  change  to  selected  directory.’ 
else 


cd  tduaay 
echo  ’  ’ 

echo  ’Directory  CHANSED  to  :  'tduaay 
echo  ’  -  Directory  changed.’  »  tteaplog 
endif  t  read  authorization  test  tor  nea  dir 
echo  ’  ’ 

echo  -n  ’  Press  (RETURN)  to  continue  ->  ’ 

set  duaay  =  (to 
echo  ’  ’ 

echo  -n  tbell’  PLEASE  MAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS.’ 

breaks* 


echo  ’Nain  select  :  V2EN  or  PRINT  tiles’  »  tteaplog 
echo  -n  ’Do  you  aish  to  V(iea)  or  P(rint)  tiles  ?  ->’ 
set  duaay  =  (tO 

echo  -n  tbell’  PLEASE  MIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS.’ 

saitch  (tduaayl 

case  ’P’:  *  UPPER  CASE  REQUIRED  FOR  ACCURACY 
echo  ’Rain  select  :  PRINT  tile  listed  beloa:’  »  tteaplog 
clear 

echo  ’Enter  the  exact  naae(s)  ot  the  tile(s)  you  aish  to  print  and  press  (RETURN).  ’ 

echo  ’  ’ 

set  prnttile  *  lt<) 

echo  ’  ’ 

echo  -n  tbell’  PLEASE  NAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS.’ 

clear 

it  (ttprnttile  ==  ’O’)  then  t  invalid  request 
echo  ’You  should  enter  a  filenaae. ’tbell 
echo  ’  -  NO  tilenaae  arguaents.’  »  tteaplog 
else 

echo  ’  -  ’tprnttile  »  tteaplog 
t  test  to  see  it  user  has  read  access  before  printing 
foreach  due_a  (tprnttile) 
if  (  -r  tdue_a  )  then 
I  print  only  ordinary  files 
if  (  -f  tdua.a  )  then 
echo  ’  -  Printing.’  »  tteaplog 
echo  ’Printing  -  ’ 
echo  -n  ’  -  ’tdua_a 
vpr  tdua  a 

echo  ’  -’DONE  PRINTING,  ’tbell 
echo  ’  -  DONE  Printing.’  >>  tteaplog 
else 

echo  ’  -  PRINT  ABORTED:  File  is  not  printable.’  »  tteaplog 
echo  ’  -  PRINT  ABORTED:  File  is  not  printable. ’tbell 
endif  •  printable  test  for  file 
else 

echo  ’PRINT  ABORTED:  You  aay  not  read  the  specified  file. ’tbell 
echo  ’  -  PRINT  ABORTED:  User  does  not  have  read  access  to  specified  file.’  »  tteaplog 
endif  I  read  access  test 
end  Iforeach  file  naae  entered 
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endif  t  nuaber  of  filenaaes  entered 
echo  ’  ’ 

echo  -n  ’  Press  (RETURN)  to  continue  ->  ’ 

set  duaay  =  («) 
echo  ’  ’ 

echo  -n  (bell’  PLEASE  NAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS.’ 

breaks*  t  print 

case  ’V’:  I  UPPER  CASE  REQUIRED  FOR  ACCURACY 
echo  'Main  select  :  VIEM  files  listed  beloa:’  »  iteaplog 
clear 

echo  ’Enter  the  exact  naae(s)  of  the  file(s)  you  aish  to  vie*  and  press  (RETURN). 

echo  ’  ’ 

set  vieafile  =  ($<) 

echo  '  ’ 

echo  -n  (bell’  PLEASE  NAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS.’ 

clear 

if  (  ilvieafile  ==  ’0’  1  then  I  no  arguaents 
echo  ’You  should  enter  a  filenaae.’lbell 
echo  ’  *  NO  filenaae  arguaents.’  »  Steep log 
else 

echo  '  -  ’(vieafile  »  iteaplog 
I  test  to  see  if  user  alloaed  to  vie*  the  files 
foreach  dua_a  (tvieafile) 
if  1  -r  <dua_a  )  then 
f  vie*  only  ordinary  files 
if  (  -f  (dua.a  1  then 
echo  ’  -  Vieaing.  ’  »  iteaplog 
echo  'VIEHIN6  :  ’tdua.a 
aore  -d  (dua_a 

echo  ’  -  DONE  viewing.’  »  iteaplog 
else 
clear 

echo  ’  -  VIEH  ABORTED:  ’idue  a’  is  not  ASCII.’  »  iteaplog 
echo  (bell’VlEN  ABORTED:  ’Idue. a’  is  not  ASCII.’ 
end if  I  printable  test  for  file 
else 
clear 

echo  tbell’VIEN  ABORTED:  You  aay  not  vie*  the  specified  file. ’(bell 
echo  ’  -  VIEH  ABORTED:  User  aay  not  vie*  the  specified  file.’  »  iteaplog 
endif  I  read  access  test 
echo  ’  ’ 

echo  -n  ’  Press  (RETIBIN)  to  continue  ->  ’ 

set  duaay  =  1(0 
echo  ’  ’ 

echo  -n  (bell’  PLEASE  WAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS.’ 

end  I  foreach  dua^a  in  duaay 
endif  I  nuaber  of  filenaaes  entered 
breaks*  I  vie* 

default: 

echo  ’VIEW  or  PRINT  :  Invalid  option.  You  aust  use  UPPER  CASE.’ 
echo  ’VIEH  or  PRINT  :  Invalid  option  ->  ’(duaay  »  iteaplog 
echo  ’  ’ 


C-13 


echo  -n  ’ 
set  duaay  =  <(() 
echo  ’  ’ 
echo  -n  (bell* 

breaks*  4  default  vie*  or  print 
endsa  I  vie*  or  print 
breaks*  <  aain  case  S 

case  ’6’: 

echo  ’Rain  Select  :  HELP’  »  tteaplog 
set  donelearn  *  (false 
•  HELP  Henu 
while  M (donelearn) 
clear 

set  infoselect  =  ’0’ 
echo  '  »hi  INSTRUCTIONS  •**«’ 

echo  ’  ’ 

echo  ’  1.  EXIT  the  HELP  Node.’ 

echo  ’  ’ 

echo  ’  2.  Search  UNIX  Manuals  by  KEYNORD. ’ 

echo  ’  ’ 

echo  ’  3.  Read  a  particular  UNIX  aanual  entry.’ 

echo  ’  ’ 

echo  ’  4.  Read  help  inforaation  for  a  particular  COURSE.’ 

echo  ’  ’ 

echo  ’  5.  Read  HELP  inforaation  for  a  particular  TOOL.’ 

echo  ’  * 

if  ((access  >  1)  then 

echo  ’  4.  Read  HELP  for  toolkit  REPORTS.’ 

echo  ’  ’ 

endif  I  access  >  1 
if  ((access  >  2)  then 

echo  ’  7.  Read  HELP  for  toolkit  MODIFICATIONS.’ 

echo  ’  ’ 

echo  ’  8.  Read  HELP  for  toolkit  UTILITY  prograas.’ 

echo  ’  ’ 

endif  •  access  >  2 

echo  -n  ’  Enter  Your  Choice  then  press  (RETURN)  ->  ’ 

set  infoselect  *  («) 
echo  ’  ’ 

echo  -n  (bell’  PLEASE  NAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS.’ 

snitch  (  (infoselect  ) 
case  ’1’: 

echo  'Help  Select  :  EXIT  HELP’  »  (teaplog 
set  donelearn  *  (true 


case  ’2’: 

echo  -n  ’Help  Select  :  Unit  Key  Search  using  -  ’  »  (teaplog 
clear 

echo  -n  ’Enter  Key*ord(s)  ->  ’ 


Press  (RETURN)  to  continue  -)  ’ 

PLEASE  NAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS 


set  duaay  =  ($<) 

echo  tduaay  »  tteaplog 

clear 

echo  'Searching  UNIX  aanuals  ...  please  wait.’ 
echo  ’  ’ 

aan  -k  tduaay  !  aore 
echo  ’  ' 

echo  -n  '  Press  (RETURN)  to  continue  ->  ’ 

set  duaay  *  (10 
echo  '  ’ 

echo  -n  their  PLEASE  WAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS.' 

laksa 

se  ’3': 

echo  -n  ’Help  Select  :  Read  UNIT  sanual  -  ’  »  tteaplog 
clear 

echo  -n  ’Enter  UNIX  Manual  IS  ->  ’ 

set  duaay  =  (t<) 

echo  tduaay  »  tteaplog 

clear 

echo  'Locating  UNIX  annual  ->  'tduaay'  ...  please  aait.’ 
echo  ’  ’ 
aan  tduaay 
echo  ’  ’ 

echo  -n  ’  Press  (RETURN)  to  continue  -)  ’ 

set  duaay  =  (t() 
echo  ’  ’ 

echo  -a  tbell’  PLEASE  MIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS.’ 

taksa 

«  ’4’: 

echo  -n  ’Help  Select  :  Course  -  ’  ))  tteaplog 
clear 

echo  -n  ’Enter  Course  ID  ->  ’ 
set  duaay  =  <t() 
echo  tduaay  ))  tteaplog 
clear 

echo  ’Searching  for  HELP  for  course  -)  ’tduaay’  ...  please  aait.’ 
echo  ’  ’ 

if  (  -e  tperadoc/tduaay’_help’  )  then 
clear 

echo  ’  -  HELP  for  course  :  ’tduaay’  presented.’  ))  tteaplog 
echo  ’HELP  for  course  -)  ’tduaay 
echo  ’  ’ 

aore  -d  tperadoc/tduaay’ .help’ 
else 

echo  ’Help  for  course  ’tduaay’  is  not  available.’ 
echo  ’  -  Help  for  course  ’tduaay’  not  available.’  ))  tteaplog 
endif  I  look  for  the  help  file 
echo  ’  ’ 

echo  -n  ’  Press  (RETURN)  to  continue  -)  ’ 

set  duaay  =  (t<) 
echo  ’  ’ 
echo  -n  tbell’ 


PLEASE  NAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS. 


breaks* 


case  ’S’: 

echo  -n  ’Help  Select  :  Tool  -  *  »  tteaplog 
clear 

echo  -n  'Enter  Tool  Naee  ->  ’ 
set  duuy  =  ($0 
echo  tduaay  »  tteeplog 
clear 

echo  'Searching  Tor  HELP  for  tool  -  'tduaay'  ...  please  aait.’ 
echo  ’  ’ 

if  I  -e  tperadoc/tduaay'_help’  1  then 
dear 

echo  ’  -  HELP  for  tool  :  'tduaay'  presented.’  »  tteeplog 
echo  'HELP  for  tool  ->  'tduaay 
echo  '  ' 

aore  -d  tperadoc/Muaay’ .help’ 
else 

echo  tbell’Help  for  tool  ’tduaay’  is  not  available.’ 
echo  ’  -  Help  for  tool  ’tduaay’  not  available.’  »  tteaplog 
endif  t  look  for  the  help  file 
echo  ’  ’ 

echo  -n  ’  Press  (RETURN)  to  continue  ->  ’ 

set  duaay  =  <t<) 
echo  ’  ’ 

echo  -n  tbell*  PLEASE  NAIT.  00  NOT  DEPRESS  ADDITIONAL  KEYS.’ 

breaks* 

case  ’A’: 

if  (taccess  >1)  then 

echo  ’Help  Select  :  toolkit  REPORTS  ’  »  tteaplog 
clear 

echo  ’Locating  HELP  for  toolkit  REPORTS  ...  please  uait.’ 
echo  ’  ’ 

if  (  -e  tperndoc/’reports_help’  )  then 
clear 

echo  ’  -  HELP  for  REPORTS  presented.’  »  tteaplog 
echo  ’HELP  for  REPORTS  :  ’ 
echo  ’  ’ 

aore  -d  tperadoc/’reportsjielp’ 
else 

echo  tbell’Help  for  REPORTS  is  not  available.’ 
echo  ’  ■  Help  for  REPORTS  not  available.’  »  tteaplog 
endif  t  look  for  the  help  file 
echo  ’  ’ 

echo  -n  ’  Press  (RETURN)  to  continue  -)  ’ 

set  duaay  =  (t() 
echo  ’  ’ 

echo  -n  tbell'  PLEASE  NAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS, 

endif  •  access  )  1 
breaks* 


se  '7': 

if  (taccess  )  2)  then 


echo  ’Help  Select  :  toolkit  MODIFICATIONS’  »  fteeplog 
clear 

echo  ’Locating  HELP  for  toolkit  MODIFICATIONS  ...  please  wait. ' 
echo  '  ’ 

if  (  -e  tperadoc/’aods.help’  )  then 
clear 

echo  ’  -  HELP  for  MODIFICATIONS  presented.’  »  fteeplog 
echo  'HELP  for  MODIFICATIONS  :  ’ 
echo  ’  ’ 

acre  -d  tperadoc/’aods.help’ 
else 

echo  tbell’Help  for  MODIFICATIONS  is  not  available.’ 
echo  ’  -  Help  for  MODIFICATIONS  not  available.’  »  fteaplog 
endif  I  look  for  the  help  file 
echo  ’  ’ 

echo  -n  ’  Press  <RETURN>  to  continue  ->  ’ 

set  duaay  -  ($0 
echo  ’  ’ 

echo  -n  fbell’  PLEASE  MA1T.  DO  NOT  DEPRESS  ADDITIONAL  KEYS, 

endif  t  access  >  2 
breaksu 

case  ’fl’: 

if  (f access  >  2)  then 

echo  ’Help  Select  :  toolkit  UTILITIES’  »  fteaplog 
clear 

echo  ’Locating  HELP  for  toolkit  UTILITIES  ...  please  eait.' 
echo  ’  ’ 

if  (  -e  tperadoc/’utils.help’  1  then 
clear 

echo  ’  -  HELP  for  UTILITIES  presented.’  »  fteaplog 
echo  'HELP  for  UTILITIES  :  ’ 
echo  ’  ’ 

aore  -d  tperadoc/’utils.help’ 
else 

echo  tbell’Help  for  UTILITIES  is  not  available.’ 
echo  ’  -  Help  for  UTILITIES  not  available.’  »  fteaplog 
endif  t  look  for  the  help  file 
echo  ’  ’ 

echo  -n  ’  Press  <RETURN>  to  continue  ->  ’ 

set  duaay  =  (t<) 
echo  ’  ’ 

echo  -n  fbell’  PLEASE  NAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS, 

endif  I  access  >  2 
breaksa 

endsu  I  help  aenu  suitch 
end  I  help  aenu  uhile  loop 
breaksu  I  aain  aenu  suitch  for  HELP 

* 

I  back  to  aain  aenu  case  choices 

I 

case  ’7’: 

set  done.report*  tfalse 
if  (taccess  >  I)  then 


f,  808  while  ! (tdone.report) 

clear 

echo  '(lain  select:  -  Generate  REPORTS.*  >>tteeplog 
*  REPORTS  HENU 

set  reptselect  *  *0’ 

echo  ’  *  *  #  *  TOOLKIT  REPORT  HENU  *  *  *  «’ 

echo  ’  ’ 
echo  ’  ’ 

echo  ’  1.  USER  ACTIVITY  report  for  specific  users.* 

echo  ’  ’ 

echo  ’  2.  SESSION  count  for  particular  aonth.* 

echo  ’  ’ 

echo  ’  3.  EXIT  report  aenu.’ 

echo  ’  ’ 

echo  -n  *  Select  ONE  option  then  press  (RETURN)  ->  ’ 

set  reptselect  5  ($0 

echo  -n  tbell’  PLEASE  NAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS, 

switch  ((reptselect) 


case  *1’: 

echo  ’Report  select  :  USER  ACTIVITY’  »  tteaplog 
clear 

echo  ’Enter  the  coaplete  path  to  filenaae  aith  target  users.’ 

set  dua.a 

set  due_a  =  ($0 

echo  ’  ’ 

echo  -n  'Please  aait  ...  reading  your  list  -  ’ 
if  (««dua_a  >  0)  then 
if  (  -e  tdua.a)  then 
set  duab  =  'cat  tdua.a' 
echo  ’DONE.’ 

<  open  a  teap  file  to  hold  report 

echo  ’  »#»*»»  USER  ACTIVITY  REPORT  *»*««’  »  tteapath'.act' 

echo  ’  ’  »  tteapath'.act’ 

echo  -n  ’  As  of  ’  »  tteapath'.act* 

date  »  tteapath'.act* 

echo  ’  ’  »  tteapath'.act* 

echo  ’User  ID  Activity’  »  tteapath'.act' 

echo  ’  ’  »  tteapath'.act* 

t  send  the  report  to  user  terainal 

clear 

echo  ’  »»•***  USER  ACTIVITY  REPORT  t#t««’ 

echo  ’  ’ 

echo  -n  ’  As  of  ’ 

date 

echo  ’  ’ 

echo  ’User  ID  Activity’ 
echo  ’  ’ 

foreach  dua_c  (tdua_b) 

set  dua.d  =  'fgrep  -k  -c  ’User  ID  :  ’tdua.c  tperalog* 
echo  tdua.c’  ’tdua.d  »  tteapath'.act* 

echo  tdua.c’  ’tdua.d 

end  t  foreach 


echo  -n  ’PLEASE  WAIT  -  printing  report  - 
vpr  Iteapath'.act* 
echo  tbell’DONE.’ 

echo  ’  -  Report  coepleted.’  >>  Iteaplog 
else 

echo  Ibell’ Cannot  open  your  user  list.’ 
echo  ’  -  Cannot  open  user  list. * >>  Iteaplog 
endif  I  read  user  list 
else  I  not  enough  arguaents 
echo  ibeH’NQ  FILE  NAIt  of  users  to  eiaaine.’ 
echo  ’  -  NO  FILE  NAME  of  users  to  exaaine.’  »  Iteaplog 
endif  (arguaents  test 
echo  ’  ’ 

echo  -n  '  Press  (RETURN)  to  continue  ->  ’ 

set  duaay  =  (10 
echo  ’  ’ 

echo  -n  Ibell’  PLEASE  MA1T.  DO  NOT  DEPRESS  ADDITIONAL  KEYS.1 

breaks* 

case  ’2’: 

echo  -  ’Report  select  :  SESSION  COUNT  for  -  ’  »  Iteaplog 
clear 

echo  -n  ’Enter  the  three-letter  abbreviation  for  aonth  ->  ’ 
set  dua_a  =  (10 
echo  ’  ’ 

echo  ldua_a  »  Iteaplog 

set  dua.b  *  ’egrep  -c  'Session  ID  :  ..'ldua_a  Iperalog* 
echo  ’  ’ 

echo  ’There  aere  ’ldue_b’  sessions  in  ’ldua_a  »  Iteaplog 
echo  ’There  acre  ’ldua_b’  sessions  in  ’ldua_a 
echo  ’  ’ 

echo  -n  ’  Press  <RETURN>  to  continue  ->  ’ 

set  duaay  =  (10 
echo  ’  ’ 

echo  -n  Ibell'  PLEASE  HAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS, 

breaks* 

case  ’3’: 

set  done_report  =  Itrue 
echo  ’Report  select:  -  EXIT.’  »  Iteaplog 
breaks*  I  exit  report  aenu 

default: 

echo  ’Report  select  :  INVALID  selection.’  »  Iteaplog 
breaks* 

ends*  I  report  aenu 
end  >  report  *hile  loop 
endif  I  access  >  1 
breaks* 

case  'O’: 

(  UTILITIES  HENU 
if  (laccess  >  2)  then 


set  utilselect  =  ’0’ 

echo  ’  ♦  *  *  *  UTILITY  PROGRAM  MENU  *  *  *  ♦’ 

echo  ’  ’ 
echo  ’  ’ 

echo  ’  1.  ADD  to  An  Authorized  User  List’ 

echo  ’  ’ 

echo  ’  2.  DELETE  froa  An  Authorized  User  List’ 

echo  ’  ’ 

echo  ’  3.  VIEW  Toolkit  STATISTICS’ 

echo  ’  ’ 
echo  ’  ’ 

echo  -n  ’  Select  ONE  option  then  press  <RETURN>  ->  ’ 

set  utilselect  *  (t<) 

echo  -n  Shell’  PLEASE  WAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS.’ 

switch  (Suti 1  select) 
case  M’: 

echo  ’Util  Select  :  ADD  to  User  List’  »  tteaplog 
clear 

echo  -n  ’Additions  filenaae  ->  ’ 
set  duaay  =  ($0 

echo  '  -  Additions  list  is  :  ’tduaay  »  tteaplog 
echo  ’Please  Hait.  Testing  List.’ 
if  (  -r  tduaay)  then 
set  dua_a  -  'cat  tduaay' 

echo  -n  ’List  Read.  Add  these  users  to  access  level  (1-3)  ->  ’ 
set  duaay  =  (tO 

echo  ’  -  Add  to  user  list  for  level  ’tduaay  »  tteaplog 
clear 

echo  'PROCESSING  ADDITIONS  :  Please  Hait.’ 
echo 

foreach  dua_b  (tdua_a) 

set  dua_c  =  'fgrep  -i  -c  tdua.b  tdata_access/tusersCtduoayl ' 
if  (tdua.c  <  1)  then 

echo  tdua_b  »  tdata, access/ tusersCfduaayl 
echo  tdua_b’  -  added  to  ’tusersltduaayl 
echo  tdua_b’  added  to  ’tusersltduaayl  >>  tteaplog 
else 

echo  tdua_b’  -  ignored  ...  already  in  list.’ 
endif  I  dua_c  test 
end  I  foreach  dua_b 
echo  ’  ’ 

echo  ’Additions  Coapleted.’tbeil 
echo  ’  -  Additions  Coapleted.’  >>  tteaplog 
else 

echo  'ADO  ABORTED:  Could  not  read  specified  file.’tbell 
echo  ’ADD  ABORTED:  Could  not  read  specified  file.’  »  tteaplog 
endif  I  test  for  read  access 
echo  ’  ’ 

echo  -n  ’  Press  (RETURN)  to  continue  ->  ’ 

set  duaay  =  (t<) 
echo  ’  ’ 
echo  -n  tbell’ 


PLEASE  HAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS. 
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case  '2’: 

echo  ’Util  Select  :  DELETE  free  User  List’  »  tteaplog 
clear 

echo  -n  ’Deletions  filename  ->  ’ 
set  duaay  ~  (10 

echo  ’Please  Wait.  Testing  list.' 
echo  ’  -  Deletion  list  is:  ’tduaay  >>  tteaplog 
it  (  -r  (duaay)  then 
set  dua.a  =  'cat  (duaay1 

echo  -n  ’List  Read.  What  access  level  (1-3)  are  these  users  ->  ’ 
set  duaay  =  («) 

echo  ’  -  Delete  troa  user  list  tor  level  'tduaay  »  (teaplog 
clear 

echo  ’PROCESS I N8  DELETIONS.  Please  Wait.’ 
echo  ’  ’ 

set  dua.b  =  'cat  tdata.access/tusersttduaayl' 
echo  -n  ’  ’  »  tteapath'.lst*  I  create  a  teap  list 
toreach  dua_c  ((dua_a) 
foreach  dua_d  ((dua.b) 
it  (tdua.d  ==  tdua.c)  then 
echo  ’  -  ’tdua.c’  deleted.’  »  tteaplog 
echo  tdua.c’  -  deleted.’ 
else 

echo  tdua.d  »  (teapath'.lst* 
endit  I  dua_d  test 
end  t  toreach  dua.d 
set  dua.b  «  'cat  (teapath’.lst" 
ra  -t  (teapath'.lst* 
end  <  toreach  dua.c 
ra  -t  tdata.access/tusersttduaayl 
echo  (dua.b  >  tdata.access/tusersttduaayl 
echo  'Deletions  Coapleted.’ 
echo  ’  -  Deletions  Coapleted.’  »  (teaplog 
else 

echo  ’DELETE  ABORTED:  Could  not  read  specified  tile.’tbell 
echo  'DELETE  ABORTED:  Could  not  read  specified  file.’»  tteaplog 
endit  I  read  access  test 
echo  ’  ’ 

echo  -n  ’  Press  (RETURN)  to  continue  ->  ’ 

set  duaay  =  («) 
echo  ’  ’ 

echo  -n  (bell’  PLEASE  NAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS.’ 

breaks* 

case  ’3’: 

echo  ’Util  Select:  VIEW  Statistics’  >>  tteaplog 
clear 

echo  -n  ’TOOLKIT  STATISTICS:  As  of  ’ 
date 

echo  ’  ’  >)  (teaplog 

echo  -n  ’TOOLKIT  STATISTICS:  As  of  ’  »  (teaplog 
date  »  (teaplog 
echo  ’  ’ 

I  dua.a  =  1 
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ihile  (4dui_a  <=  4f stats) 

8  du«_b  =  4dua_a  ♦  1 

echo  4statsI4dui_a]’  :  ’4statsl4dui_b] 

echo  4stats(*dui_aJ’  :  'tstitsttdu§_h]  »  Iteiplog 

8  dui_a  =  4dui_a  +  2 

end  <  while  loop 

echo  ’  ’ 

echo  -n  ’  Press  (RETURN)  to  continue  -)  ’ 

set  duiiy  =  (40 
echo  ’  ’ 

echo  -n  Obeli’  PLEASE  WAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS.’ 

breaks! 

default: 

echo  ’  -  No  util  aenu  selection.’  >)  Oteiplog 
breaks!  4  default  util  ienu 


ends!  i  utility  ienu  siitch 
endif  I  access  )=  2 
breaks!  t  lain  case  8 


case  ’9’: 

t  MODIFICATION  MENU 
if  (Oaccess  >  2)  then 
clear 

set  aodselect  =  ’0’ 

echo  '  t««f  MODIFICATION  MENU  tttt’ 

echo  ’  ’ 
echo  ’  ’ 

echo  ’  1.  ADD  a  toolkit  component.’ 

echo  ’  ’ 

echo  ’  2.  DELETE  a  toolkit  component.’ 

echo  ’  ’ 

echo  ’  3.  HOVE  a  toolkit  component.’ 

echo  ’  ’ 
echo  ’  ’ 

echo  -n  ”  Select  ONE  option  then  press  (RETURN)  -)  ’ 

set  aodselect  *  (40 

echo  -n  4bell’  PLEASE  NAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS.’ 

siitch  (4aodselect) 

case  ’1’: 
dear 

echo  ’Mods  select:  ADD  component.’  ))  4teiplog 
echo  ’Enter  coiplete  current  path  to  component:’ 
set  dui_a  *  (40 

echo  ’Enter  coiplete  destination  path  for  component:’ 

set  dui_b  =(40 

if  (  -r  4dui_a  )  then 

echo  ’Adding  nei  component:’ 
echo  ’  Froi:  ’4dui_a 
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echo  ’  To:  ’tdue_b 
echo  ’Adding  ne«  component:’  ))  tteeplog 
echo  ’  Froe:  'tduea  »  tteeplog 
echo  ’  To:  ’tdue_b  »  tteeplog 
cp  (due  a  tdue  b 
echo  tbell’  COMPONENT  ADDED.’ 
endif  t  -r  read  test 
echo  ’  ’ 

echo  -n  ’  Press  (RETURN)  to  continue  ->  ’ 

set  duaey  =  (t<) 
echo  ’  ’ 

echo  -n  tbell’  PLEASE  NAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS. 

breaksN 

case  ’2’: 
clear 

echo  ’Nods  select:  DELETE  coeponent.’  »  tteeplog 
echo  ’Enter  coeplete  current  path  to  coeponent:’ 
set  d ue_a  =  lt<) 
if  <  -«e  tdue_a  )  then 

echo  ’Deleting  coeponent:  ’tdue_a 
echo  'Deleting  coeponent:  ’tdue.a  »  tteeplog 
echo  -n  ’ARE  YOU  SURE  ?  Y(es)  N(o>  ->  ’ 
set  dueey  =  (t<) 
snitch  (t dueey) 

case  ’Y’: 

echo  ’Deletion  verified.’  »  tteeplog 
re  -f  tdue_a 
echo  tduaa’  reeoved.’ 
echo  tdue_a’  reeoved.’  »  tteeplog 
breaks* 

default: 

echo  ’CAPITAL  Y  not  entered.' 
echo  ’Deletion  ABORTED  at  user  request.’ 
echo  ’Deletion  ABORTED  at  user  request.’  »  tteeplog 
breaks* 
ends*  t  duaey 
else 

echo  ’Deletion  ABORTED  :  Could  not  delete.’  »  tteeplog 
echo  'Deletion  ABORTED  :  Could  not  delete.’ 
endif  t  *«  *rite  test 
echo  ’  ’ 

echo  -n  ’  Press  (RETURN)  to  continue  -)  ' 

set  dueey  =  ($0 
echo  ’  ’ 

echo  -n  tbell’  PLEASE  BAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS, 

breaks* 

case  ’3’: 
clear 

echo  ’Hods  select:  HOVE  coeponent.’  ))  tteeplog 
echo  ’Enter  coeplete  current  path  to  coeponent:’ 
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set  dun_a  -  (40 

echo  ’Enter  complete  destination  path  for  coaponent:’ 
set  dua.b  =  (40 
if  (  -r  Idua.a  1  then 
echo  ’ Roving  coaponent:’ 
echo  ’  Froa:  ’tdua.a 

echo  ’  To:  ’tdua_b 

echo  ’Roving  coaponent:’  »  tteaplog 
echo  '  Froa:  ’tdua_a  »  tteaplog 

echo  ’  To:  ’idua.b  »  tteaplog 

av  tdua  a  tdua  b 
echo  tbell 'HOVE  COHPLETED. ’ 
else 

echo  ’Hove  ABORTED  :  Cannot  read  source.’  »  tteaplog 
echo  'Rove  ABORTED  :  Cannot  read  source.’  »  tteaplog 
endif  t  -r  read  test 
echo  ’  ’ 

echo  -n  ’  Press  < RETURN!  to  continue  ->  ’ 

set  duaay  =  (t<) 
echo  ’  ’ 

echo  -n  tbell’  PLEASE  WAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS.’ 

breaks* 

default: 

echo  ’  -  No  aod  aenu  selection.'  »  tteaplog 
breaks*  I  default  aods 

ends*  •  aod  aenu 

endif  t  access  >  2 
breaks*  t  aain  aenu  case  9 

default: 

echo  ’User  being  provided  HELP  «ith  RAIN  select.’  »  tteaplog 
clear 

aore  -d  tperadoc/aain.help 
echo  ’  ’ 

echo  -n  ’  Press  <RETURN>  to  continue  ->  ’ 

set  duaay  «  (t<) 
echo  ’  ’ 

echo  -n  tbell’  PLEASE  NAIT.  DO  NOT  DEPRESS  ADDITIONAL  KEYS.’ 

breaks* 

ends*  I  aain  aenu  s*itch 

end  I  aain  aenu  while  loop 

( 

I  END  OF  RAIN  SELECTION  LOOP 

I 

close  kit:  t  label  for  juap  after  user  interrupt  of  prograa 
I  «•»♦  NETT  CORHAND  REROVES  INTERRUPT  CAPABILITY  TO  SHELL 
«  UNTIL  THE  TOOLKIT  IS  CLOSED 
onintr  - 

I 

clear 
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1186  if  (taain  aenu  !=  *1’  U  tdone_aain  ’1’)  then 

1187  echo  ’1  N  T  E  R  R  U  P  T  £  D_-  BY  USER  ’  »  lte.pl oq 

1188  echo  tbell’  IMTERRUPTED-BY  USER' 

1189  echo  ’  ’ 

1190  endif  I  report  interrupt 

1191  echo  ’  Locking  VLSI  CAD  toolkit.  There  are  5  steps  required.’ 

1192  echo  ’  ’ 

1193  echo  STEP  -  Reaarks’ 

1194  echo  -n  01  -  Saving  Systea  Status  :  ’ 

1195  echo  ’  ’  »  tteaplog 

1196  echo  -n  'SESSION  CLOSED  AT  :  ’  »(teaplog 

1197  date  »  tteaplog 

1198  a  -u  »  tteaplog 

1199  echo  '  ’  »  tteaplog 

1200  echo  ’Closing  status  of  systea  storage  :  ’  »  tteaplog 

1201  df  »  tteaplog 

1202  echo  ’SAVED.’ 

1203  echo  -n  ’-  02  -  Updating  Statistics  :  ’ 

1204  if  (taccess)  then 

1205  8  stats(21  =  tstats(21  -  1  I  nuaber  of  active  users  reduced  by  1 

1206  endif  t  delete  one  user  if  there  was  a  valid  user  session 

1207  echo  tstats  >  ttoolkit_stats  •  update  the  stat  file 

1208  echo  ’UPDATED.’ 

1209  echo  -n  ’-  03  -  Closing  Session  Log  :  ’ 

1210  echo  ’  ’  »  tteaplog 

1211  echo  ’TOOLKIT  STATISTICS:  At  session  close:’  »  tteaplog 

1212  8  dua.a  -  1 

1213  while  (idue.a  <*  tlstats) 

1214  8  duab  =  tdua_a  ♦  1 

1215  echo  tstatsltdua_al’  :  ’tstats[tdua_bl  »  tteaplog 

1216  8  dua  a  *  tdua_a  *  2 

1217  end  •  while  loop 

1218  echo  ’  ’  »  tteaplog 

1219  if  (tbackgrnd)  then 

1220  set  dua.a  =  ‘ps’ 

1221  echo  tdua_a  »  t  teaplog 

1222  echo  ”  >>  tteaplog 

1223  endif  •  save  process  status  to  see  what  jobs  were  running 

1224  echo  ’=«=«====>  »  tteaplog 

1225  I 

1226  cat  tteaplog  »  tperalog 

1227  echo  ’DONE.’  t  closing  the  logs 

1228  I  reaove  all  teaporary  files  created  during  this  session 

1229  echo  -n  ’-  04  -  Reaoving  Teaporary  Files  :  ’ 

1230  t 

1231  ra  -f  tteapath* 

1232  echo  ’DONE.’ 

1233  echo  -n  ’-  05  -  Returning  control  to  the  operating  systea  ...’ 

1234  I  end  session  -  update  stats 

1235  stty  intr  ’*?’  susp  ”T  quit  ,A\’ 

1236  clear 

1237  if  (tbackgrnd)  then 

1238  echo  ’You  initiated  background  jobs  during  this  session’ 


tr 


Program  2:  A  "C"  Program  Used  to  Protect  The  Toolkit 
The  program  listed  below,  written  in  the  "C"  language, 
has  been  provided  to  this  author  courtesy  of  Mr  Joe  Hamlin, 
AFIT/AD.  The  manager  of  the  toolkit  may  effectively  "hide" 
the  toolkit  from  direct  access  by  other  users  by  performing 
two  tasks:  1)  giving  read,  write,  and  execute  permission 
for  all  toolkit  components  only  to  the  "owner"  of  the  custo¬ 
dian  script  and  2)  conditioning  the  custodian  script  with 
the  program  provided  below.  The  program,  setu.c,  condi¬ 
tions  a  script  by  setting  the  script's  user  permissions  so 
that  the  script  will  respond  to  a  user  as  if  the  user  were 
its  "owner".  In  this  way,  users  may  access  toolkit  compo¬ 
nents  via  the  custodian  and  its  "conditioned"  permissions 
even  though  the  users  do  not  possess  operating  system  per¬ 
missions  to  directly  access  toolkit  components. 

/***************  BEGIN  setu.c  ************/ 

main(argc,  argv,  envp) 
int  argc; 

char  *argv[],  **envp; 

( 

char  *strcat(); 
char  cmd[100]; 

cmd [0]  =  ' \0 ' ; 

strcat(cmd,  "/usr/ local/cad/trv/vlsi_tool_kit/scr . " )  ; 
strcat(cmd,  argv[0])? 
setgid (31) ; 

execve(cmd,  argv,  envp); 

) 

/*************** *end  setu.c  ***************/ 

The  implementation  of  this  protection  program  is 
accomplished  as  shown  below: 
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1.  Edit  setu.c  so  that  it  contains  the  correct 

path  name  to  your  script.  Like: 

/usr/ local /cad/ trv/vlsi_cad_toolkit/scr .custodian. 

2.  The  script  should  have  a  name  like 

scr .name 

3.  The  first  line  in  the  script  must  be 

# 1 /bin/csh 

4.  Compile  setu.c  with 

cc  -o  setu  setu.c 

5.  Set  special  protection  bits  with 

chmod  4711  setu 

6.  Move  to  the  directory  where  the  script  is  to 
be  used. 


7.  Type:  "In  setu  name".  This  links  "setu"  with 
the  script  "name".  When  the  script  "name"  is 
executed,  it  will  execute  as  though  the  user  had 
ownership  permissions. 


Appendix  D:  Application  of  the  Evaluation  Metrics 

to  the  Prototype  Custodian 


AFIT  VLSI  CAD  Toolkit  Custodian  Evaluation  Formulas 

The  evaluation  formulas  and  scales  provided  below,  cop¬ 
ied  from  chapter  5,  have  been  used  to  evaluate  the  prototype 
custodian  detailed  in  Appendix  C. 


Drawer  Component  Evaluation  Formula : 


DCQ 


t  EV(i) 


x  CL(i)  ] 


n 


(EQ  1) 


Where  : 


DCQ  =  Drawer  Component  Quality  (overall) 

EV  *  Essentiality  Value  of  characteristic 
i 

CL  *  Characteristic  Level  of 
characteristic  i 

n  =  Number  of  characteristics  being 
evaluated 


Drawer  Evaluation  Formula: 


DQ 


(  EV(i) 


x  DCQ(i)  ] 


n 


(EQ  2) 


Where  : 


DQ  =  Drawer  Quality  (overall) 

DCQ  *  Drawer  Component  Quality  of  drawer 
component  i 

EV  =  Essentiality  Value  of  drawer  j 

component  i  < 

n  =  Number  of  drawer  components  ; 

I 

< 
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The  scale  shown  below  provides  a  measure  of  the  pre- 


\V 

sence  of  a  desired  characteristic. 


<r# 


Characteristic 
Level  (CL) 

3 

2 

1 

0 

-1 


Degree  to  Which  Characteristic 
is  Present  in  this  Component 

The  desired  characteristic  is 
entirely  present. 

The  desired  characteristic  is 
mostly  present. 

The  desired  characteristic  is 
somewhat  present. 

The  desired  characteristic  is 
completely  absent. 

Characteristics  are  present 
which  are  somewhat  detrimental 


“2  Characteristics  are  present 

which  are  very  detrimental 

-3  Characteristics  are  present 

which  are  unacceptable 


Evaluation  of  the  Prototype  Custodian: 

The  evaluation  of  the  prototype  custodian  is  provided 
below.  This  evaluation  is  intended  to  illustrate  the  tech¬ 
nique  for  evaluating  drawer  components  as  well  as  the 
drawer  itself.  A  comparison  is  provided  between  the  maximum 
possible  scores  and  the  scores  computed  based  upon  this 
author's  evaluation.  The  maximum  possible  Drawer  Component 
Quality  (DCQ)  for  each  drawer  component  was  computed  by 
assigning  the  Characteristic  Level  (CL)  value  "3"  (the  high¬ 
est  possible  value)  to  each  characteristic  being  rated.  The 
maximum  Drawer  Quality  (DQ)  was  computed  using  the  maximum 
possible  DCQ  for  each  component. 
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Component  Evaluations : 


A.  Custodian  -  User  Interface  Components: 

Component  Description  Rating  Data 


1.  The  custodian  provides  the  only  user  in¬ 
terface  to  the  toolkit. 


E 


Desired  Component  Characteristics 

EV 

CL 

xC 

la.  No  toolkit  component  can  be  viewed 
without  custodian  assistance. 

16 

3 

48 

lb.  No  toolkit  component  can  be  printed 
without  custodian  assistance. 

16 

3 

48 

lc.  No  toolkit  component  can  be  executed 
without  custodian  assistance. 

32 

3 

96 

Id.  No  toolkit  component  can  be  moved  or 
copied  without  custodian  assistance. 

32 

3 

96 

Highest  Possible  DCQ: 

Overall  Drawer  Component  Quality  (DCQ) : 
Essentiality  Value  (EV)  for  component: 

72 

72 

32 

Component  Description  Rating  Data 


2.  The  custodian  provides  the  capability  to 
easily  select  toolkit  components  at  any 
design  level. 


E 

Desired  Component  Characteristics  EV  CL  xC 


2a.  Selection  of  toolkit  components  is  8  1  8 

possible  via  a  hierarchy  of  menus. 

2b.  Selection  of  components  is  adaptable  16  1  16 

to  suit  user  familiarity  with  the  toolkit 
(eg:  fully  menu-driven  for  novice  and 

reduced  menu  presentation  for  expert) . 

2c.  The  custodian  can  provide  access  to  32  3  96 

all  toolkit  components. 


2d.  The  custodian  provides  access  to  16 
toolkit  components  with  a  minimum  number 
of  user  keystrokes. 


Highest  Possible  DCQ:  54 
Overall  Drawer  Component  Quality  (DCQ) :  38 
Essentiality  Value  (EV)  for  component:  16 


Component  Description 


Rating  Data 


3.  The  custodian  provides  on-line  help  and 
aid  to  the  user  at  each  decision  point. 


E 


Desired  Component  Characteristics 

EV 

CL 

xC 

3a.  User  help  is  available  for  the  cus¬ 
todian-user  interface. 

32 

1 

32 

3b.  User  help  is  available  for  each 
toolkit  drawer. 

8 

1 

8 

3c.  User  help  is  available  for  each 
drawer  component. 

16 

1 

16 

3d.  User  help  is  available  at  the  user's 
request  at  any  time  prior  to  a  response 
to  a  custodian-generated  question. 

32 

0 

0 

3e.  User  help  for  error  resolution  is 
available  immediately  following  any  error 
condition  arising  from  the  execution  of  a 
toolkit  component. 

2 

0 

0 

Highest  Possible  DCQ: 

54 

Overall  Drawer  Component  Quality  (DCQ) : 

11. 

2 

Essentiality  Value  (EV)  for  component: 

8 

Component  Description 

Rating 

Data 

4.  The  custodian  provides  meaningful  feed¬ 
back  concerning  user  entries. 


E 

Desired  Component  Characteristics  EV  CL  xC 


4a.  The  custodian  echoes  user  inputs  to  2  0  0 

custodian-generated  questions. 

4b.  The  custodian  requests  user  verifi-  16  2  32 

cation  for  "dangerous"  requests  (eg: 
deletion  of  a  file) . 

4c.  The  custodian  identifies  input  er-  8 
rors  to  the  nearest  word  containing  the 
error. 


8 


Desired  Component  Characteristics 


4d.  Immediately  following  a  user  input  8 
the  custodian  advises  the  user  that  the 
input  is  being  processed. 

4e.  Custodian-generated  error  messages  16 
are  complete  sentences. 

4f .  Feedback  is  provided  for  each  user  32 
requested  action. 

Highest  Possible  DCQ: 

Overall  Drawer  Component  Quality  (DCQ) : 
Essentiality  Value  (EV)  for  component: 


Component  Description 


5.  The  custodian  provides  logical,  syntacti¬ 
cal,  and  physical  error  detection  as  well  as 
the  ability  to  recover  from  errors. 


Rating  Data 


Desired  Component  Characteristics 


5a.  The  custodian  permits  the  user  to  16 
edit  an  input  which  contained  an  error 
and  does  not  require  the  user  to  re-enter 
the  entire  input. 

5b.  The  custodian  screens  all  user  input  16 
arguments  for  correctness  prior  to  any 
attempt  to  execute  a  toolkit  component 
which  requires  the  input  arguments. 

5c.  The  custodian  does  not  cease  execu-  32 
tion  if  an  error  occurs  in  the  user  input 
data. 


5d.  The  custodian  does  not  cease  execu¬ 
tion  if  a  component  aborts  execution  due 
to  an  error. 

5e.  The  custodian  always  ceases  execu¬ 
tion  in  a  "graceful"  manner. 

Highest  Possible  DCQ: 

Overall  Drawer  Component  Quality  (DCQ) : 
Essentiality  Value  (EV)  for  component: 


6.  The  custodian  provides  the  capability  to 
select  an  interface  display  that  matches  user 
equipment . 


EV 

Desired  Component  Characteristics  EV  CL  xCL 


6a.  The  custodian  provides  the  user  with  16  0  0 

the  ability  to  select  a  terminal 

definition  from  a  menu  of  terminals. 

6b.  The  custodian  provides  a  means  for  16  0  0 

the  user  to  test  their  terminal 

selection. 


6c.  The  custodian  will  permit  toolkit  32  3  96 

operation  from  a  non-video  terminal. 

6d.  The  custodian  permits  the  use  of  8  3  24 

user-written  custom  terminal  descrip¬ 
tions  . 


Highest  Possible  DCQ:  54 
Overall  Drawer  Component  Quality  (DCQ) :  30 
Essentiality  Value  (EV)  for  component:  16 


Component  Description 


Rating  Data 


7.  The  custodian  provides  full  access  to 
user-selectable  options  in  component  tools. 


EV 

Desired  Component  Characteristics  EV  CL  xCL 


7a.  The  custodian  prompts  the  user  for  8  2 

entry  of  the  minimum  number  of  arguments 
needed  to  execute  a  requested  tool. 

7b.  The  user  is  prompted  for  optional  8  2 

arguments  when  a  tool  execution  is  re¬ 
quested. 

7c.  No  allowable  tool  option  is  filtered  32  3 

from  the  user  input  stream  by  the 
custodian. 


16 


16 


96 


Highest  Possible  DCQ: 

Overall  Drawer  Component  Quality  (DCQ) : 
Essentiality  Value  (EV)  for  component: 


48 

42.7 

32 


u 


Component  Description 

Rating 

Data 

8.  The  custodian  provides  the  ability  to 
identify  user-selectable  data  required  by 
component  tools. 

Desired  Component  Characteristics 

EV 

CL 

EV 

xCL 

8a.  The  custodian  permits  the  user  to 
identify  files  containing  data  for  use 
during  tool  execution. 

32 

3 

96 

Highest  Possible  DCQ: 

Overall  Drawer  Component  Quality  (DCQ) : 
Essentiality  Value  (EV)  for  component: 

96 

96 

32 

Component  Description 

Rating 

Data 

9.  The  custodian  provides  an  interface  that 
is  simple  enough  to  service  very  inexperien¬ 
ced  users  and  flexible  enough  to  meet  the 
demands  of  expert  users. 

Desired  Component  Characteristics 

EV 

CL 

EV 

xCL 

9a.  The  custodian  permits  the  user  to 
identify  their  level  of  toolkit  exper¬ 
tise. 

32 

3 

96 

9b.  The  custodian  considers  the  user- 
identified  level  of  toolkit  expertise 
each  time  a  message  is  sent  to  the  user 
terminal . 

16 

1 

16 

Highest  Possible  DCQ: 

Overall  Drawer  Component  Quality  (DCQ) : 
Essentiality  Value  (EV)  for  component: 

72 

56 

8 

Component  Description 

Rating 

Data 

10.  The  custodian  provides  selectable  levels 
of  input  assistance. 


Desired  Component  Characteristics 


EV 


CL 


EV 

XCL 


10a.  The  custodian  generates  help  mes-  32  0  0 

saqes  based  upon  the  user-identified 
level  of  toolkit  expertise. 


D-8 


Highest  Possible  DCQ: 

Overall  Drawer  Component  Quality  (DCQ) : 
Essentiality  Value  (EV)  for  component: 


96 

0 

8 


Component  Description 


Rating  Data 


11.  The  custodian  provides  meaningful  feed¬ 
back  during  the  execution  of  toolkit  compo¬ 
nents. 

EV 


Desired  Component  Characteristics 

EV 

CL 

xCL 

11a.  The  custodian  signals  the  start  of 
execution  of  any  toolkit  component. 

16 

2 

32 

lib.  The  custodian  signals  the  comple¬ 
tion  of  the  execution  of  any  toolkit 
component. 

16 

2 

32 

11c.  The  custodian  advises  whether  or 
not  any  toolkit  component  execution  was 
successfully  completed. 

32 

1 

32 

lid.  The  custodian  signals  the  start  and 
finish  of  every  custodian  activity. 

2 

0 

0 

Highest  Possible  DCQ: 

Overall  Drawer  Component  Quality  (DCQ) : 
Essentiality  Value  (EV)  for  component: 

49.5 

24 

8 

Component  Description  Rating  Data 


12.  The  custodian  provides  command  names 
which  may  be  customized  for  user  convenience. 

EV 

Desired  Component  Characteristics  EV  CL  xCL 


12a.  The  custodian  permits  the  user  to  32  0  0 

identify  a  series  of  ASCII  characters  to 
be  associated  with  a  user-selected  name. 

12b.  The  custodian  provides  automatic  32  0  0 

substitution  of  user-specified  characters 
whenever  a  user-defined  command  is  en¬ 
countered. 

Highest  Possible  DCQ:  96 

Overall  Drawer  Component  Quality  (DCQ) :  0 

Essentiality  Value  (EV)  for  component:  2 


Component  Description 


Rating  Data 


13.  The  custodian  provides  the  ability  to 
identify  a  file  of  commands  which  are  to  be 
executed  as  though  they  were  real-time  user 
inputs . 

E’ 

Desired  Component  Characteristics  EV  CL  xC 


13a.  The  custodian  will  read  a  user  32  0  0 

specified  file  and  examine  each  line  of 
the  file  as  though  it  was  a  toolkit  com¬ 
mand  sequence. 

13b.  The  custodian  executes  valid  com-  32  0  0 

mands  extracted  from  a  user-specified 
file  as  though  they  were  input  directly 
from  the  user  terminal. 


Highest  Possible  DCQ:  96 
Overall  Drawer  Component  Quality  (DCQ) :  0 
Essentiality  Value  (EV)  for  component:  2 


Component  Description 


Rating  Data 


14.  The  custodian  provides  the  ability  to 
tailor  output  messages  to  include  user  speci¬ 
fied  data. 

E 

Desired  Component  Characteristics  EV  CL  xC 


14a.  The  custodian  provides  the  user  32  0  0 

with  the  ability  to  select  additional 
message  data. 


14b.  The  custodian  includes  user-select-  32  0  0 

ed  additional  output  data  in  all  custo¬ 
dian-generated  messages  to  the  user. 


Highest  Possible  DCQ:  96 
Overall  Drawer  Component  Quality  (DCQ) :  0 
Essentiality  Value  (EV)  for  component:  2 


Component  Description 


Rating  Data 


15.  The  custodian  provides  verification  that 
the  data  and  tools  necessary  to  fulfill  user 
requests  are  available  to  the  toolkit. 


0 


0 


Desired  Component  Characteristics  EV 


15a. 
tence 
files 
nent . 

The  custodian  verifies  the  exis- 
and  availability  of  user-owned 

needed  to  execute  a  toolkit  compo- 

32 

0 

0 

15b. 

tence 

files 

nent. 

The  custodian  verifies  the  exis- 
and  availability  of  toolkit-owned 
needed  to  execute  a  toolkit  compo- 

32 

3 

96 

15c.  The  custodian  verifies  the  exis¬ 
tence  and  availability  of  toolkit 
components  requested  by  the  user. 

32 

3 

96 

15d. 

tence 

nents 

The  custodian  verifies  the  exis- 
and  availability  of  toolkit  compo- 
needed  by  other  toolkit  components 

16 

0 

0 

during  execution  of  a  user-requested 
operation. 


Highest  Possible  DCQ:  84 
Overall  Drawer  Component  Quality  (DCQ) :  48 
Essentiality  Value  (EV)  for  component:  32 


B.  Custodian  Access  Control  Components: 

Component  Description  Rating  Data 


1.  The  custodian  controls  access  to  the 
toolkit,  individual  drawers,  and  individual 
drawer  components  on  a  user-to-user  basis. 


EV 

Desired  Component  Characteristics  EV  CL  xCL 


la.  The  custodian  assigns  an  access  32  3  96 

level  code  to  each  user  of  the  toolkit. 

lb.  The  custodian-assigned  access-level  32  2  64 

code  clearly  identifies  each  user's 

access  to  any  toolkit  component. 

lc.  The  custodian  maintains  lists  of  16  3  48 

users  separated  by  their  toolkit  access 
authorizations . 


Desired  Component  Characteristics 


Id.  The  custodian  permits  the  users  with  16 
authorization  to  modify  toolkit  compo¬ 
nents  with  the  ability  to  modify  the  user 
access  lists. 

Highest  Possible  DCQ: 

Overall  Drawer  Component  Quality  (DCQ) : 

Essentiality  Value  (EV)  for  component: 


Component  Description 


Rating  Data 


2.  The  custodian  verifies  a  potential  user's 
access  authorizations  in  a  manner  that  does 
not  reveal  the  method  used  to  determine  ac¬ 
cess  nor  the  access  authorizations  of  other 
toolkit  users. 

Desired  Component  Characteristics 

2a.  User  access  lists  are  accessible  32 
only  to  those  users  authorized  to  change 
the  lists. 

2b.  User  access  lists  are  not  displayed  32 
or  referenced  in  any  message  during  ac¬ 
cess  verification 

Highest  Possible  DCQ: 

Overall  Drawer  Component  Quality  (DCQ) : 
Essentiality  Value  (EV)  for  component: 


Component  Description  Re 


3.  The  custodian  provides  an  audit  trail  of 
repeated  attempts  to  access  the  toolkit  by  an 
unauthorized  user. 

Desired  Component  Characteristics 


3a.  The  custodian  can  determine  if  a  32 
user  access  list  has  been  compromised. 

3b.  The  custodian  stores  information  32 

which  is  sufficient  to  identify  any  un¬ 
authorized  user  who  attempts  to  access 
the  toolkit. 


Rating  Data 


D-12 
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3c.  The  list  of  unauthorized  users  is  16  2  32 

maintained  with  the  same  security 
constraints  as  the  lists  of  authorized 
users . 

Highest  Possible  DCQ:  80 

Overall  Drawer  Component  Quality  (DCQ):  42.7 

Essentiality  Value  (EV)  for  component:  8 


Component  Description  Rating  Data 


4.  The  custodian  maintains  a  history  of  all 
toolkit  sessions. 

EV 

Desired  Component  Characteristics  EV  CL  xCL 


4a.  The  custodian  maintains  a  log  of  all  16  3  48 

user  activity,  on  a  user-by-user  basis, 
during  each  toolkit  session. 

4b.  The  toolkit  history  identifies  each  16  3  48 

execution  of  the  toolkit  on  a  user-by- 
user  basis. 

4c.  The  toolkit  history  identifies  the  32  3  96 

date  and  time  that  each  user  session 
began  and  ended. 

4d.  The  toolkit  history  identifies  each  16  3  96 

toolkit  component  executed  during  a  user 

session. 

4e.  The  toolkit  history  identifies  the  16  0  0 

date  and  time  that  each  toolkit  component 
execution  began  and  ended. 

4f.  The  toolkit  history  identifies  the  8  3  24 

status  of  the  system  load  and  storage 
capacities  at  the  beginning  and  end  of 
each  user  session. 

4g.  The  toolkit  history  identifies  the  16  2  32 

number  of  times  the  toolkit  has  been 
accessed  during  any  particular  period  of 
time . 

4h.  The  toolkit  history  identifies  the  16  2  32 

number  of  times  any  particular  user  or 
group  of  users  has  accessed  the  toolkit 
during  any  particular  period  of  time. 


D-13 


Desired  Component  Characteristics 


EV 

EV  CL  xCL 


4i.  The  toolkit  history  identifies  the  16  2  32 

number  of  times  that  any  particular  tool¬ 
kit  component  has  been  accessed  during 
any  particular  period  of  time. 

4j.  The  toolkit  history  identifies  the  32  0  0 

date  that  any  particular  toolkit  compo¬ 
nent  was  last  modified. 


Highest  Possible  DCQ: 

Overall  Drawer  Component  Quality  (DCQ) : 
Essentiality  Value  (EV)  for  component: 


55.2 

40.8 

32 


Component  Description 


Rating  Data 


5.  The  custodian  controls  access  to  each 
drawer  component. 

EV 


Desired  Component  Characteristics 

EV 

CL 

xCL 

5a.  No  drawer  component  may  be  executed 
without  custodian  assistance. 

32 

3 

96 

5b.  No  drawer  component  may  be  printed 
without  custodian  assistance. 

16 

3 

48 

5c.  No  drawer  component  may  be  viewed 
without  custodian  assistance. 

16 

3 

48 

5d.  No  drawer  component  may  be  moved  or 
copied  without  custodian  assistance. 

32 

3 

96 

5e.  No  drawer  component  may  be  changed 
without  custodian  assistance. 

32 

0 

0 

Highest  Possible  DCQ: 

Overall  Drawer  Component  Quality  (DCQ) : 
Essentiality  Value  (EV)  for  component: 

76.8 

57.6 

32 

C.  Information  Control  Components: 


Component  Description 


1.  The  custodian  controls  the  flow  of  infor¬ 
mation  into,  within,  and  out  of  the  toolkit. 


Rating  Data 


Desired  Component  Characteristics 


la.  All  information  required  for  the 
execution  of  any  toolkit  component  either 
resides  in  the  toolkit,  is  identified  by 
the  user  in  response  to  custodian  ques¬ 
tions,  or  is  a  integral  part  of  the  oper¬ 
ating  system  of  the  computer  supporting 
the  toolkit. 


lb.  The  existence  and  availability  of  16 
all  information  needed  to  execute  a 
toolkit  component  is  verified  by  the 
custodian  prior  to  the  execution  of  the 
component . 


Highest  Possible  DCQ: 

Overall  Drawer  Component  Quality  (DCQ) : 
Essentiality  Value  (EV)  for  component: 


Component  Description 


Rating  Data 


2.  Input  data  is  analyzed  to  ensure  that  it 
is  in  a  format  which  is  compatible  with  the 
toolkit  formats  or  in  a  format  which  is  ac¬ 
ceptable  to  the  data  translation  tools  avail¬ 
able  in  the  toolkit.  Improperly  formatted 
data  is  rejected. 


Desired  Component  Characteristics 


2a.  User-identified  data,  needed  for 
component  execution,  is  checked  to  ensure 
it  is  in  a  format  compatible  with  the 
component  or  with  a  toolkit  data 
translation  tool. 


Desired  Component  Characteristics 


2b.  Unacceptable  input  data  is  rejected  32 
and  the  reason  for  rejection  is  identi¬ 
fied  to  the  user. 


Highest  Possible  DCQ: 

Overall  Drawer  Component  Quality  (DCQ) : 
Essentiality  Value  (EV)  for  component: 


D-15 
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Component  Description 


Rating  Data 


3.  All  user  input  data  is  treated  as  tempor¬ 
ary  or  transient  data. 

EV 

Desired  Component  Characteristics  EV  CL  xCL 


3a.  All  non-resident#  user-identified  16  0  0 

data  needed  for  the  execution  of  a  custo¬ 
dian  action  or  toolkit  component  is  cop¬ 
ied  to  the  toolkit  temporary  storage 
drawer  prior  to  utilization. 

3b.  Data  residing  in  the  toolkit  tempor-  16  1  16 

ary  storage  drawer  is  removed  when  no 
longer  needed  for  the  execution  of  a 
toolkit  component. 


Highest  Possible  DCQ:  48 
Overall  Drawer  Component  Quality  (DCQ) :  8 
Essentiality  Value  (EV)  for  component:  8 


Component  Description 


Rating  Data 


4.  User  requests  to  add,  delete,  or  modify 
permanent  toolkit  data  are  stored  by  the 
custodian  for  review  by  the  person (s)  respon¬ 
sible  for  the  toolkit  configuration. 

EV 

Desired  Component  Characteristics  EV  CL  xCL 


4a.  User  requests  to  modify  the  toolkit  32  0  0 

data  are  stored  in  the  toolkit  temporary 
storage  drawer. 

4b.  When  the  toolkit  is  accessed  by  a  16  0  0 

user  who  is  authorized  to  modify  the 
toolkit,  user-requested  toolkit  modifica¬ 
tions  are  presented  to  that  user  prior  to 
the  execution  of  any  toolkit  component. 


Highest  Possible  DCQ:  72 
Overall  Drawer  Component  Quality  (DCQ) :  0 
Essentiality  Value  (EV)  for  component:  32 


Component  Description 


Rating  Data 


5.  Once  data  has  been  moved  to  permanent 
storage,  the  custodian  prevents  modification 
of  the  data  by  any  user  in  subsequent  design 
sessions . 


D-16 
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Desired  Component  Characteristics 

EV 

CL  xC 

5a.  Only  those  users  with  proper  access 
levels  may  view,  copy,  or  modify  data 
residing  in  the  toolkit  permanent  storage 
drawer. 

32 

3  96 

Highest  Possible  DCQ: 

96 

Overall  Drawer  Component  Quality  (DCQ) : 

96 

Essentiality  Value  (EV)  for  component: 

32 

Component  Description 

Rating  Data 

6.  Once  acquired,  user  input  data  is  in¬ 
ternally  controlled  and  translated  as  needed 
for  tool  use. 

Desired  Component  Characteristics 


6a.  The  custodian  is  aware  of  the  data 
formats  required  by  each  of  the  toolkit 
components . 

6b.  User  access  to  data  stored  in  the 
toolkit  temporary  storage  drawer  is  de¬ 
nied  while  that  data  is  being  used  by  a 
toolkit  component. 

Highest  Possible  DCQ: 

Overall  Drawer  Component  Quality  (DCQ) : 
Essentiality  Value  (EV)  for  component: 


0  0 


2  32 


Component  Description 


7.  Access  to  any  and  all  temporary  or  perma 
nent  data,  either  by  the  user  or  by  a  resi 
dent  tool  is  controlled  by  the  custodian. 


Rating  Data 


Desired  Component  Characteristics 


7a.  Access  to  all  resident  data  by  a  32 

user  is  controlled  by  the  custodian. 

7b.  Access  to  all  resident  data  by  a  32 

toolkit  component  is  controlled  by  the 
custodian. 


Highest  Possible  DCQ: 

Overall  Drawer  Component  Quality  (DCQ) : 
Essentiality  Value  (EV)  for  component: 


Component  Description 


Rating  Data 


8.  All  data  output  during  a  design  session 
is  delivered  via  the  custodian. 

EV 

Desired  Component  Characteristics  EV  CL  xCL 


8a.  No  data  is  delivered  to  a  storage  32  2  64 

area  outside  the  toolkit  unless  the 

storage  area  is  identified  and  approved 

by  the  custodian.  Data  paths  which  are 

integral  to  toolkit  component  structures 

are  approved  by  the  custodian. 

Highest  Possible  DCQ:  96 

Overall  Drawer  Component  Quality  (DCQ) :  64 

Essentiality  Value  (EV)  for  component:  32 


D.  Drawer  Sequence  Control  Components: 


Component  Description  Rating  Data 


1.  The  custodian  controls  the  sequence  in 
which  toolkit  drawers  are  opened  and  closed. 
Toolkit  components  which  access  other  toolkit 
drawers  due  to  their  integral  structure  are 
considered  to  be  controlled  by  the  custodian. 


Desired  Component  Characteristics  EV  CL  xCL 


la.  No  toolkit  drawer  is  accessed  unless  32  3  96 

access  is  accomplished  via  the  custodian 
or  due  to  the  integral  structure  of  a 
toolkit  component. 

Highest  Possible  DCQ:  96 

Overall  Drawer  Component  Quality  (DCQ) :  96 

Essentiality  Value  (EV)  for  component:  32 


E.  Sequence  Control  Components: 

1.  The  custodian  controls  the  sequence  in 
which  toolkit  components  are  executed.  Tool¬ 
kit  components  which  execute  other  toolkit 
components  due  to  their  integral  structure 
are  considered  to  be  controlled  by  the  custo¬ 
dian. 
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a 


;v 
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Desired  Component  Characteristics 


la.  No  toolkit  component  is  executed  32  3  96 

unless  execution  is  accomplished  via  the 
custodian  or  due  to  the  integral  struc¬ 
ture  of  a  toolkit  component. 


Highest  Possible  DCQ:  96 
Overall  Drawer  Component  Quality  (DCQ) :  96 
Essentiality  Value  (EV)  for  component:  32 


F.  Parameter  Control  Components: 


Component  Description 


Rating  Data 


1.  The  custodian  controls  the  parameters 
used  during  the  execution  of  component  tools. 

E 

Desired  Component  Characteristics  EV  CL  xC 


la.  Whenever  possible  the  custodian  as-  2  0 

signs  default  component  execution  para¬ 
meters  prior  to  requesting  user-specified 
parameters. 

lb.  User  specified  parameters  have  32  0 

precedence  over  custodian-assigned  de¬ 
fault  parameters. 

lc.  The  value  of  all  parameters  needed  32  1 

for  the  execution  of  a  toolkit  component 

are  established  via  custodian  action 
prior  to  the  execution  of  any  component. 


0 


0 


32 


Highest  Possible  DCQ: 

Overall  Drawer  Component  Quality  (DCQ) : 
Essentiality  Value  (EV)  for  component: 


66 

10.7 

16 


G.  Toolkit  Modification  Components: 


Component  Description  Rating  Data 


1.  The  custodian  controls  additions  and 
modifications  to  the  toolkit  drawers  and 
their  components. 


Desired  Component  Characteristics 

EV 

CL 

la.  No  addition  can  be  made  to  the  tool¬ 
kit  without  the  assistance  of  the  custo¬ 
dian. 

32 

2 

Desired  Component  Characteristics 

EV 

CL 

lb.  No  modification  can  be  made  to  the 
toolkit  without  the  assistance  of  the 
custodian. 

32 

1 

Highest  Possible  DCQ: 

Overall  Drawer  Component  Quality  (DCQ) : 
Essentiality  Value  (EV)  for  component: 

96 

48 

32 

Overall  Drawer  Rating 


Summary  of  Drawer  Component  Qualities  (DCQ) 

Where:  EV  *  Essentiality  Value  of  the  COMPONENT. 


Component  Max  Actual  Max  Actual 

Identifier  DCQ  DCQ  EV  x  DCQ  EV  x  DCQ 


n 


Component 

Max 

Actual 

Max 

Actual 

n 

Identifier 

DCQ 

DCQ 

EV  x  DCQ 

EV  x  DCQ 

23 

C3 

48 

8 

384 

64 

24 

C4 

72 

0 

2304 

0 

25 

C5 

96 

96 

3072 

3072 

26 

C6 

72 

16 

1152 

256 

27 

C7 

96 

64 

3072 

2048 

28 

C8 

96 

64 

3072 

2048 

29 

D1 

96 

96 

3072 

3072 

30 

El 

96 

96 

3072 

3072 

31 

FI 

66 

10.7 

1056 

171.6 

32 

G1 

96 

48 

3072 

1536 

3)  Ratio  of  Actual  DQ  to  Maximum  Possible  OQ: 

Actual  DQ  1173.54 

-  =  -  =  .67 

Max  DQ  Poss  1753.38 

4)  Actual  DQ  Percentage  of  Maximum  DQ  Possible:  67  % 
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